Hi all,
I would like to ask you for some help about LISP (CLISP).
I am a professional programmer with more than ten years of experience in
C/C++ and (not so many years) with Tcl/Tk. I have worked in many software
projects and I think I understand fairly well computers and the software
development process.
I am also working on my PHD as a hobby and I am interested in moving some
software which I developed for Maple to LISP.
And here come my questions:
1. Which lisp should I use? (I currently work with Linux). I now have gcl
and clisp in my computer, but I do not know which is better.
2. I find most of the books good, but oriented to users with no programming
experience, so many practical things (like reading ascii files and
converting their contents into symbols, or dealing with strings) usually are
left out and I find myself with no reference about functions and procedures
to do simple things (things that I could do fairly quickly in C/Tcl). Does
anybody know about any book or document with such an orientation?
3. Is it possible to build executables? Maybe this is a silly question, but
I haven't found any clear information about this (or I haven't known how to
find it). Even more: I would like to mix C/C++ and LISP, but I don't know if
this is possible (I am sure it is, but I found no documentation).
I know that his are not easy questions, so let me thank you for your
patience (specially if you have read up to this point).
Christian
In article <·············@SGI3651ef0.iddeo.es>, "Christian Pomar"
<·····@ieeee.org> wrote:
> And here come my questions:
>
> 1. Which lisp should I use? (I currently work with Linux). I now have gcl
> and clisp in my computer, but I do not know which is better.
CLISP seems to be more actively maintained. I have used it in a number
of projects.
Other Lisp systems on Linux:
CMU CL : cool compiler-based system. Free.
www.cons.org
ACL : commercial ("free" version for some purposes).
www.franz.com
LispWorks : commercial. A "personal edition" is available.
Full development environment.
http://www.xanalys.com/software_tools/products/lwl.html
> 2. I find most of the books good, but oriented to users with no programming
> experience, so many practical things (like reading ascii files and
> converting their contents into symbols, or dealing with strings) usually are
> left out and I find myself with no reference about functions and procedures
> to do simple things (things that I could do fairly quickly in C/Tcl). Does
> anybody know about any book or document with such an orientation?
Norvig's PAIP is an advanced text (http://www.norvig.com).
The ANSI CL Hyperspec is online and several Lisp systems are coming
with extensive documentation.
> 3. Is it possible to build executables? Maybe this is a silly question, but
> I haven't found any clear information about this (or I haven't known how to
> find it). Even more: I would like to mix C/C++ and LISP, but I don't know if
> this is possible (I am sure it is, but I found no documentation).
You can build executables with most Lisp systems and you can link
in foreign code (there is no standard for that, though).
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
"Christian Pomar" <·····@ieeee.org> writes:
>1. Which lisp should I use? (I currently work with Linux). I now have gcl
>and clisp in my computer, but I do not know which is better.
gcl is quite undermaintained. It has some special features and some
people still use it for one of them. But the usual choice is Clisp
for a "nice", approchable implementation and CMUCL for an
implementation that is capable of producing fast code.
You can also get non-cost Linux/FreeBSD versions of Allegro CL (very
limited) Lispworks (even more limited).
>2. I find most of the books good, but oriented to users with no programming
>experience, so many practical things (like reading ascii files and
>converting their contents into symbols, or dealing with strings) usually are
>left out and I find myself with no reference about functions and procedures
>to do simple things (things that I could do fairly quickly in C/Tcl). Does
>anybody know about any book or document with such an orientation?
Paul Graham's "ANSI Common Lisp" is better in listing Common Lisp
functionality required for working applications than the "programming
introdution" books.
Reference on functions is built into Common Lisp, see (apropos ...)
and (documentation ...). Also check out the ilisp emacs package which
adds keystrokes to access that documentation from your Lisp and also
from...
... the ANSI CL standard that is available as HTML tarfile and is
easily converted to pure plain ASCII (and is still readable then).
>3. Is it possible to build executables? Maybe this is a silly question, but
>I haven't found any clear information about this (or I haven't known how to
>find it). Even more: I would like to mix C/C++ and LISP, but I don't know if
>this is possible (I am sure it is, but I found no documentation).
Write a simple shell script wrapper to call a Lisp application by one
commandline name. That way, you can also process commandline switches
using Unix getopt(1) and transfer that into suitable Lisp expressions
and hence give your application a more familiar look to Unix users.
Loading C files is built into each Lisp in a different way.
Loading C++ libraries requires a C wrapper around it and must not
depend on fancy linker features, such as that no statically allocated
objects call constructurs. Throwing exceptions is also not
advertised. Obviously, you cannot use template libraries from Lisp.
Think of it like you were dynamically loading C++ code into a C/C++
application, that are the same restructions^H^H^H CRAP. Did I mention
that C++ is not really easy to make happy with anything else :-)
I wonder when I get to see a piece of C++ code that throws an
exception cause by a floating point exception trap on an object casted
via RTTI from a pure virtual private constructor out of dynamically
loaded code in a threaded application. Guru question: How do I do the
same thing in Lisp? Non-guru answer: Just do it. Given an
implementation with threads, all that other crap is built into the
language without even noticing a problem you had to define a
bussword-named solution for.
Now, how do you inspect your commercially bought binary-only C++
library for the presense of such features? No problems, RTTI code is
easy to identify in the disassembler...
I better stop before someone notices the opportunity to go into a C++
flamewar again.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
FreeBSD - where you want to go. Today. http://www.freebsd.org/
From: Jochen Schmidt
Subject: Re: Moving from C/C++/Tcl to CLisp - Some Help Please
Date:
Message-ID: <3991A1F7.A87E7E98@gmx.de>
Christian Pomar wrote:
>
> Hi all,
>
> I would like to ask you for some help about LISP (CLISP).
>
> I am a professional programmer with more than ten years of experience in
> C/C++ and (not so many years) with Tcl/Tk. I have worked in many software
> projects and I think I understand fairly well computers and the software
> development process.
>
> I am also working on my PHD as a hobby and I am interested in moving some
> software which I developed for Maple to LISP.
>
> And here come my questions:
>
> 1. Which lisp should I use? (I currently work with Linux). I now have gcl
> and clisp in my computer, but I do not know which is better.
I would recommend you CMUCL since it's a opensourced free and
super-fast
native-compiler Lisp :)
But CLISP is also a really nice Lisp-environment, especially if memory
counts.
(CMUCLs image is something around 20MB while CLISPs is ~ 2MB
CLISP runs also on much more platforms.
Note: If you want to use the MOP (Meta Object Protocol) in CLISP, you
have
to compile and load the PCL package first.
The lite-versions of the commercial Lisps are restricted some ways, but
if your
applications need not much ram, 24h uptime or Lisp-imagedumping then
they are a good solution too.
> 2. I find most of the books good, but oriented to users with no programming
> experience, so many practical things (like reading ascii files and
> converting their contents into symbols, or dealing with strings) usually are
> left out and I find myself with no reference about functions and procedures
> to do simple things (things that I could do fairly quickly in C/Tcl). Does
> anybody know about any book or document with such an orientation?
As a free and pretty good online language reference look at the
"HyperSpec"
http://www.xanalys.com/software_tools/reference/HyperSpec/
On of the best books I've read is "On Lisp" of Paul Graham. It is THE
source
for learning how to use lisp-macros. Pauls words about software-design
in Lisp
are also very valueable.
Another important book is certainly the PAIP (Paradigms of Artificial
Intelligence Programming)
by Peter Norvig. IMHO the best part are the chapters on writing highly
optimized Lisp
code.
Both books contain a short introduction to lisp in the first chapters.
>
> 3. Is it possible to build executables? Maybe this is a silly question, but
> I haven't found any clear information about this (or I haven't known how to
> find it). Even more: I would like to mix C/C++ and LISP, but I don't know if
> this is possible (I am sure it is, but I found no documentation).
The commercial "full" Lisps are able to dump executables. The only "free
of charge" Lisp which could have this option is maybe "CormanLisp" which
is Windows-only.
But much more worse no free Lisp has the ability to do a "tree-shake".
This means
that you delete all parts of the lispimage which are not used by your
application.
So you have to deliver full-images (CMUCL 20MB !!!)
Lisp applications don't grow in size so much like some other languages,
but the
minimal application size is huge. If you want to deliver several
Lisp-applications
you can let them use the same image, and start them by parametrized
shellscripts.
This would also mean faster application loading as the image would be
cached.
(The "Emacs' second start effect ;-) )
sincerely Yours
Jochen Schmidt
···@dataheaven.de
From: Martin Cracauer
Subject: Re: Moving from C/C++/Tcl to CLisp - Some Help Please
Date:
Message-ID: <8mto7g$mr0$1@counter.bik-gmbh.de>
Jochen Schmidt <··············@gmx.de> writes:
>But CLISP is also a really nice Lisp-environment, especially if memory
>counts.
>(CMUCLs image is something around 20MB while CLISPs is ~ 2MB
I'd like to remark that this is disk space, not neccessarily RAM.
If the code you are trying to run is small and uses few of the
library, you easily end up with CMUCL needing less RAM. The reason is
that CMUCL just mmap's its image and sends sends the processor's
program counter into native code in such a region. Only the code you
call is being paged in by the operating system, just like with a
native Unix executable. A bytecode system on the other hand has to
load the bytecode interpreter, which in turn often uses large chunks
of Common Lisp. Also, data is represented in a very compact way in
CMUCL.
Having said this, for a general-purpose system, especially with a GUI,
Clisp usually needs less RAM.
[...]
>But much more worse no free Lisp has the ability to do a "tree-shake".
>This means
>that you delete all parts of the lispimage which are not used by your
>application.
>So you have to deliver full-images (CMUCL 20MB !!!)
If you build CMUCL with :small in *features*, the image goes down from
20 to 12.5 MB. If you don't use CLOS, leaving out PCL saves 2-3 more
megabytes.
Again, RAM usage increases with :small, although the image looks much
smaller. Startup time of CMUCL with :small or of Clisp is also much
more than "normal" CMUCL.
>Lisp applications don't grow in size so much like some other languages,
>but the
>minimal application size is huge. If you want to deliver several
>Lisp-applications
>you can let them use the same image, and start them by parametrized
>shellscripts.
>This would also mean faster application loading as the image would be
>cached.
>(The "Emacs' second start effect ;-) )
Exactly. The effect is even bigger in non-:small CMUCL since CPU
overhead for starting your code is essentially zero.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
FreeBSD - where you want to go. Today. http://www.freebsd.org/
From: Brad Knotwell
Subject: Re: Moving from C/C++/Tcl to CLisp - Some Help Please
Date:
Message-ID: <qlog32r2ag.fsf@ix.netcom.com>
········@counter.bik-gmbh.de (Martin Cracauer) writes:
> Exactly. The effect is even bigger in non-:small CMUCL since CPU
> overhead for starting your code is essentially zero.
>
> Martin
I haven't seen any news for awhile about cmucl. Is it still being
actively developed and, if so, in what direction is it going for the
future?
Inquiring minds want to know.
--Brad
Centuries ago, Nostradamus foresaw a time when Brad Knotwell would say:
>········@counter.bik-gmbh.de (Martin Cracauer) writes:
>> Exactly. The effect is even bigger in non-:small CMUCL since CPU
>> overhead for starting your code is essentially zero.
>>
>> Martin
>
>I haven't seen any news for awhile about cmucl. Is it still being
>actively developed and, if so, in what direction is it going for the
>future?
>
>Inquiring minds want to know.
It _appears_ that the SBCL "project," which is seeking to build a
somewhat simpler "bootstrap" atop the Python compiler, is progressing
a bit more quickly.
There are also several projects working on "user space" code like
test suites and such, as well as the Series package.
Take a look for Common Lisp at <http://sourceforge.net/>;
there's quite a bit of stuff there...
--
········@hex.net - <http://www.hex.net/~cbbrowne/lisp.html>
Pagers are cases for holding dead batteries. -Richard Wolff
From: Martin Cracauer
Subject: Re: Moving from C/C++/Tcl to CLisp - Some Help Please
Date:
Message-ID: <8n07a8$tlu$1@counter.bik-gmbh.de>
Brad Knotwell <········@ix.netcom.com> writes:
>········@counter.bik-gmbh.de (Martin Cracauer) writes:
>> Exactly. The effect is even bigger in non-:small CMUCL since CPU
>> overhead for starting your code is essentially zero.
>>
>> Martin
>I haven't seen any news for awhile about cmucl. Is it still being
>actively developed and, if so, in what direction is it going for the
>future?
>Inquiring minds want to know.
Sure, CMUCL is what you'd call a full OpenSource project, with an
active team.
See http://www.cons.org/cmucl/
Work currently being done is to a large part polishing, moving to ANSI
CL, also adding things like Gray streams. People appear to dig deeper
and deeper into the compiler, first adding new datatypes, now pushing
for serious performance improvements, also for PCL/CLOS. On the
runtime side, there is experimental code for native (operating System)
threads (the x86 port has multiprocessing since 18b) and improving the
naive way of allocating memory regions and loading foreign code.
Support also improves, there are now three instructions for rebuilding
CMUCL, for each his own, I guess ;-), the lists are quite responsive
etc.
What is still missing is someone to write release notes for
announcements and digging around the web to eliminate all links to
outdated CMUCL pages not listing the post-CMU project.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
FreeBSD - where you want to go. Today. http://www.freebsd.org/
In article <············@counter.bik-gmbh.de>,
········@counter.bik-gmbh.de (Martin Cracauer) wrote:
> Sure, CMUCL is what you'd call a full OpenSource project, with an
> active team.
>
> See http://www.cons.org/cmucl/
>
> Work currently being done is to a large part polishing, moving to ANSI
> CL, also adding things like Gray streams. People appear to dig deeper
> and deeper into the compiler, first adding new datatypes, now pushing
> for serious performance improvements, also for PCL/CLOS. On the
> runtime side, there is experimental code for native (operating System)
> threads (the x86 port has multiprocessing since 18b) and improving the
> naive way of allocating memory regions and loading foreign code.
>
> Support also improves, there are now three instructions for rebuilding
> CMUCL, for each his own, I guess ;-), the lists are quite responsive
> etc.
Cool.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
From: Christian Pomar
Subject: Re: Moving from C/C++/Tcl to CLisp - Some Help Please
Date:
Message-ID: <8ms7h1$n28o5@SGI3651ef0.iddeo.es>
Thank you very much for your kind answers [Rainer Joswig, Martin Cracauer
and Jochen Schmidt].
It is nice to know it is possible to find some help in this world. I Hope
some day I can help in the same way somebody.
Best regards,
Christian