Hello everyone,
I am a newbie in Lisp, and I would like to know your opinion
on the following lisp/scheme implementations:
- SBCL
- Bigloo
- Guile
- newLisp
Information about which version is more actively maintained, faster,
more complete etc will be appreciated.
thanks in advance,
George
From: Edi Weitz
Subject: Re: Newbie: help me with choosing a Lisp implementation
Date:
Message-ID: <uhdlrngg9.fsf@agharta.de>
On 9 Jan 2005 00:17:37 -0800, ···················@gmail.com" <··················@gmail.com> wrote:
> I am a newbie in Lisp, and I would like to know your opinion on the
> following lisp/scheme implementations:
>
> - SBCL
> - Bigloo
> - Guile
> - newLisp
>
> Information about which version is more actively maintained, faster,
> more complete etc will be appreciated.
SBCL is an implementation of Common Lisp. It's actively maintained
and it's based on mature code. (Actually it's based on CMUCL which is
another very good option for an open source Common Lisp.)
For a brief survey of other Common Lisp implementations take a look at
<http://alu.cliki.net/implementation>.
Bigloo and Guile are Scheme implementations, so you better ask in the
Scheme newsgroup. newLisp is yet another Lisp dialect.
Before you start learning a language of the Lisp family you should
first decide which one you'd like to learn - Scheme and Common Lisp
are different enough to be viewed as two separate languages. This
text
<http://www.cs.uni-bonn.de/~costanza/lisp/guide.html>
might be helpful. (You asked this on a Lisp newsgroup, so this is the
advice you get. You might get other advice in the Scheme camp.)
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
···················@gmail.com" <··················@gmail.com> writes:
> I am a newbie in Lisp, and I would like to know your opinion
> on the following lisp/scheme implementations:
>
> - SBCL
> - Bigloo
> - Guile
> - newLisp
>
> Information about which version is more actively maintained, faster,
> more complete etc will be appreciated.
Actively maintained? Well,
- SBCL 0.8.18 was released on 2004-12-18.
Its development mailing list archive shows
62 messages so far in 2005, including several
from people I recognize as SBCL contributors.
- Bigloo 2.6e was released in 2004-04.
Its mailing list archive shows 6 messages
so far in 2005. There was one from Manuel Serrano
(one of the principal authors) in 2004-12.
- Guile 1.6.7 was released on 2004-12-21.
Its development mailing list archive shows
7 real messages so far in 2005, plus a great
deal of spam. At least some of the messages
are clearly from people actively working on
the Guile internals.
- newLisp 8.3.1 was released on 2004-11-23.
Its development mailing list ... doesn't
exist, but they have some web-based bulletin
boards that seem pretty active.
Faster? Well,
- SBCL compiles Common Lisp to native code.
Common Lisp is designed to be compilable to
efficient native code.
You can certainly make programs that run fast
using SBCL.
- Bigloo compiles Scheme to native code via C.
Scheme wasn't designed with efficiency in view
as much as CL was. On the other hand, Scheme
is a simpler language in various ways, which
may help. I've heard quite good things about
Bigloo's compiler. One of Bigloo's primary
design goals was making it practical to use
Scheme in places where it would be normal to
use C or C++; making the compiled code fast
is an important part of that.
I'm fairly sure you can make programs that
run fast using Bigloo.
- Guile doesn't have a native-code compiler,
or even (I think) a bytecode compiler.
The only way to get anything close to the
performance of SBCL using Guile would be to
write the critical parts of your program in
C. Bad news: this is a nuisance. Good news:
Guile is designed to make writing extensions
in C not-too-painful, and if you do that then
you can probably often achieve performance
better than you'd get from a purely-in-Lisp
solution with SBCL or Bigloo. (Of course SBCL
and Bigloo let you interface to C, too.)
Barring that, you're probably looking at a
factor of 10-100 slower than SBCL and Bigloo.
- newLisp doesn't have a native-code compiler,
or even (I think) a bytecode compiler.
I'd say roughly the same about newLisp as I
did about Guile.
More complete? Well,
- SBCL is a more or less complete implementation
of Common Lisp. Common Lisp is a big language.
SBCL extends Common Lisp in various ways, mostly
quite minor.
- Bigloo is a more or less complete implementation
of Scheme. Scheme is a small language. Bigloo
implements many extensions to Scheme, some of
them rather large. It probably ends up being
about as much language+library as Common Lisp.
- Guile: same as Bigloo, but a different set of
extensions. (There is substantial overlap, thanks
to an informal standards process in the Scheme
community; ask Google about "SRFI".)
- newLisp: implements a deliberately non-standard
Lisp-like language, of which newLisp is the only
implementation. I suppose you could say that that
makes it 100% complete by definition. The language
is smaller than Common Lisp or Scheme.
Some other things:
- Bigloo also compiles ML.
- Guile was originally meant to be some sort of
multiple-language extension facility for GNU
software; the idea was that there would be
multiple front-ends, so that you could extend
GNU programs using something similar to Lisp,
something similar to Python, etc. I don't think
that ever happened.
- If you want to know more about the Scheme
implementations, or about other Scheme implementations,
then you should ask on comp.lang.scheme; c.l.l is
quite firmly focused on Common Lisp.
- In both c.l.l and c.l.s you are likely to find
near-universal consensus that *as a language*
newLisp is inferior to both CL and Scheme[1]. But
it might suit your needs anyway; it's designed
to fit a certain niche that CL and Scheme aren't
generally so interested in. (If so, though, then
you might possibly want to take a quick look at
the CL implementation called CLISP.)
[1] That was what happened in c.l.l a few
months ago; I think linguistic purism
is (even) more common in c.l.s than in
c.l.l, which is why I'd expect the same
to happen there.
- Your list is a bit peculiar, on the CL side
at least. Why doesn't it include (e.g.) CLISP
and the/or freebie versions of the commercial
CL implementations?
--
Gareth McCaughan
.sig under construc
··················@gmail.com wrote:
> wow! thanks for the loooong replies!
> btw, i didnt think that scheme is THAT much different than lisp.
>
> -g.
>
If you are looking for your first Scheme/Lisp compiler, then take
a look at PLT Scheme (umbrella name for DrScheme and MzScheme).
See Bill Clementson blog for a description:
<http://home.comcast.net/~bc19191/blog/040111.html>
Note that the book on Scheme programming "How to Design Programs"
are online at <http://www.htdp.org>.
--
Jens Axel Søgaard
<http://www.schemecookbook.org>
···················@gmail.com" <··················@gmail.com> writes:
> wow! thanks for the loooong replies!
> btw, i didnt think that scheme is THAT much different than lisp.
They're closely related, but no more so than (say)
Java and C++.
--
Gareth McCaughan
.sig under construc
··················@gmail.com wrote:
> wow! thanks for the loooong replies!
> btw, i didnt think that scheme is THAT much different than lisp.
It is relative. If you consider all forms of transportation, a Ferrari
is not /that/ much different from a dump truck.
Scheme is an exercise in minimalism, CL cares more about actually
creating applications.
kt
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Kenny Tilton <·······@nyc.rr.com> writes:
> ··················@gmail.com wrote:
> > wow! thanks for the loooong replies!
> > btw, i didnt think that scheme is THAT much different than lisp.
>
> It is relative. If you consider all forms of transportation, a Ferrari
> is not /that/ much different from a dump truck.
Actually, there are less differences between a Ferrari and a dump
truck: the user interface is exactly the same, than between
Common-Lisp and Scheme, where the API is quite different and only some
fundamental ideas are the same. You'd have to compare a F16 and a
bicycle (there are gears in both!)
> Scheme is an exercise in minimalism, CL cares more about actually
> creating applications.
--
__Pascal Bourguignon__ http://www.informatimago.com/
This is a signature virus. Add me to your signature and help me to live
Kenny Tilton wrote:
> Scheme is an exercise in minimalism, CL cares more about actually
> creating applications.
Scheme is a functional exercise in minimalism; CL is a minimal
exercise in functionality.
> In both c.l.l and c.l.s you are likely to find
> near-universal consensus that *as a language*
> newLisp is inferior to both CL and Scheme[1]. But
> it might suit your needs anyway; it's designed
> to fit a certain niche that CL and Scheme aren't
> generally so interested in.
Can you please elaborate more on this? The use of
namespaces (contexts) to implememnt prototype based
oop seems very interesting. Is there a posting that elaborates
on the disadvantages of newLisp?
regards,
George
··················@gmail.com wrote:
> Is there a posting that elaborates on the disadvantages of newLisp?
<http://lambda-the-ultimate.org/node/view/257>
--
Jens Axel Søgaard
thanks for the link, and thanks to everyone for the great info!
-g.
From: Marcin 'Qrczak' Kowalczyk
Subject: Re: Newbie: help me with choosing a Lisp implementation
Date:
Message-ID: <87is66nyso.fsf@qrnik.zagroda>
···················@gmail.com" <··················@gmail.com> writes:
> Can you please elaborate more on this? The use of
> namespaces (contexts) to implememnt prototype based
> oop seems very interesting. Is there a posting that elaborates
> on the disadvantages of newLisp?
No garbage collection, no sharing of values: all values are copied
when passed as function arguments or put in data structures (except
for some builtin functions), no lexical scoping, numbers are only
fixnums and floats, silly restrictions with the only justification
being interpreter simplicity (e.g. length of quoted string constants
is limited to 2048, strings cannot contain NULs), ugly FFI which e.g.
represents pointers as integers on the newLisp side (doesn't work when
a pointer doesn't fit in C int), pointless rules like cons behaving
like list when the second argument is not a list (no practical and
safe code would make use of this).
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
From: lin8080
Subject: Re: Newbie: help me with choosing a Lisp implementation
Date:
Message-ID: <41E5B7E1.44C94622@freenet.de>
Marcin 'Qrczak' Kowalczyk schrieb:
> ···················@gmail.com" <··················@gmail.com> writes:
> > Can you please elaborate more on this? The use of
> > namespaces (contexts) to implememnt prototype based
> > oop seems very interesting. Is there a posting that elaborates
> > on the disadvantages of newLisp?
> No garbage collection, no sharing of values: all values are copied
> when passed as function arguments or put in data structures (except
> for some builtin functions), no lexical scoping, numbers are only
> fixnums and floats, silly restrictions with the only justification
> being interpreter simplicity (e.g. length of quoted string constants
> is limited to 2048, strings cannot contain NULs), ugly FFI which e.g.
> represents pointers as integers on the newLisp side (doesn't work when
> a pointer doesn't fit in C int), pointless rules like cons behaving
> like list when the second argument is not a list (no practical and
> safe code would make use of this).
But it can move the smile.bmp around the screen.
stefan
Gareth McCaughan wrote:
> ···················@gmail.com" <··················@gmail.com> writes:
> - Bigloo 2.6e was released in 2004-04.
> Its mailing list archive shows 6 messages
> so far in 2005. There was one from Manuel Serrano
> (one of the principal authors) in 2004-12.
>
Hi:
I cannot resist. It is dubious to gauge the validity by means of Bigloo
its newsgroup frequency. Not that I object your analysis which is
rather balanced and okay.
However, one of Bigloo its greatest strengths is the fact that it
delivers fast executables (the mystical a.outs). The Bigloo IDE "Bee"
is very good, though, not well documented.
Bigloo, surely is hard-core supported by Dr. Serrano. And honestly:
that will last as long as Manuel serrano is alive. Scheme, functional
programming is his job which he as a computer scientist does for a
living. Manuel is a lead author in the upcomming Scheme standard.
Nevertheless: one of the most useful features relating to Bigloo is the
fact that one may give some type informations. Oh no, the Bigloo style
will not clutter up ones code:
==
(define (fun::double in::complex x::pair y::pair-nil s::vector
j::my_object_type)
(....))
==
it is so much easier to use than:
==
(define (fun in x y s j)
())
==
The compiler spots type mismatches then, though, it is not as
sophisticated and static than OCaml for example; Bigloo types will
never stand in your way and will make you hunting compiler errors;
Scheme its freedom is still alive.
Bigloo has native pattern-matching facilities. The C integration is
easy to use,...etc.
Surely, the user base is not that huge and bindings to external C
libraries are scarce. However, I made the binding to the plotting
library DISLIN and one from MIT is working on a gsl binding in his
spare time.
Bigloo has been used for the commercial PHP compiler (it also made it
to slahdot). I asked the author why he used Bigloo and not Common Lisp
for example. One of his decision making factors were (as I rember
correctly):
- Bigloo is fast and delivers small executables
- pattern matching is good
- he is also mentioned the yacc thing; don't ask me what that is
- Bigloo has first rate support by Manuel and his students
- types
- object system
- Though Common Lisp would have much more built-in facilities but
Bigloo is half down the road to such.
Personally, I use Bigloo for numerical simulations in physics (writing
my PhD). I once tried Common Lisp but Bigloo delivers me all that what
I need with the goody that I did not have to invest to much time to get
productive with. Sorry, but Common Lisp appealed never sexy in my
eyes.
Another good option would be Dr Scheme. It shares a much greater user
base and has other goodies at its disposal.
Chicken comes also to mind.
In a nutshell: never forget Bigloo its typing system. That is one of
the cool features. The speed of Bigloo is in the same league as OCaml.
There a situations where Ocaml would be faster and then there are
situations where Bigloo would be faster. There are some tricks in
Bigloo to speed up things. Bigloo for example has basic native type
operators fl+, fl*,... such kind of things then ensure the compiler
that an array for example exclusively consits of floating point values
only. The compiler gets rather picky then.
Förster vom Silberwald
On 2005-01-10 13:12:31, F�rster vom Silberwald wrote:
> (define (fun::double in::complex x::pair y::pair-nil s::vector
> j::my_object_type)
> (....))
> ==
>
> it is so much easier to use than:
>
> ==
> (define (fun in x y s j)
You are posting in the wrong newsgroup for this argument. :-)
"F�rster vom Silberwald" <··········@hotmail.com> writes:
> Gareth McCaughan wrote:
> > ···················@gmail.com" <··················@gmail.com> writes:
>
> > - Bigloo 2.6e was released in 2004-04.
> > Its mailing list archive shows 6 messages
> > so far in 2005. There was one from Manuel Serrano
> > (one of the principal authors) in 2004-12.
> >
> Hi:
>
> I cannot resist. It is dubious to gauge the validity by means of Bigloo
> its newsgroup frequency. Not that I object your analysis which is
> rather balanced and okay.
Of course it's dubious to do that! But, um, what am I
supposed to do? I could have just said "Bigloo seems to
be under active development, but perhaps a little quieter
than SBCL". I could have said what I did say and then
drawn some conclusions. Both of those would have involved
*more* dubious validity-gauging than what I did. I can't
see any realistic option that would have involved *less*,
except maybe doing some kind of survey of the developers
of the various implementations mentioned and finding out
how much time they're spending on it. Which would have
been altogether too much trouble, since even the crude
investigation I did was enough to reveal that all the
implementations are actively being worked on.
If you read what I wrote as saying "Bigloo is not being
actively developed" then I was unclear; I certainly did
not mean to imply anything of the sort.
[SNIP: interesting Bigloo information and advocacy]
Thanks for that. But I hope you weren't hoping to
convince me that Bigloo is a very cool piece of software --
because I *already* believed that. :-) (My own preference
is for Common Lisp, but Bigloo would be high on any
sensible person's list of Scheme implementations.)
--
Gareth McCaughan
.sig under construc
Gareth McCaughan wrote:
> If you read what I wrote as saying "Bigloo is not being
> actively developed" then I was unclear; I certainly did
> not mean to imply anything of the sort.
As I said I didn't beliebe you have drawn your conclusions from the
activity on the Bigloo list; which is quite low by the way.
However, I cannot resist: comp.lang.lisp.franz has zero messages since
2005 (at least on my Google). I hope I am not heading in the wrong
direction when I believe that "Franz" is somehow related to Alegro
Common Lisp. So Alegro Common Lisp is dead - right?
> Thanks for that. But I hope you weren't hoping to
> convince me that Bigloo is a very cool piece of software --
> because I *already* believed that. :-) (My own preference
> is for Common Lisp, but Bigloo would be high on any
> sensible person's list of Scheme implementations.)
I have to cheerlead Bigloo sometimes because I find it sad that people
- not necessarily you - often count every Scheme implementation as it
were a sole Scheme implementation. Surely, every Scheme implementation
is in a different league and there is really no consensus among Scheme
implementors.
My point actually is: if one neglects all the additional goodies which
comes often bundled with a specific Scheme implementation he will miss
a lot of good features.
Surely, we are on Lisp list, but I would consider using Bigloo every
time in my own company for real-life production code If I had a
company. Personally I use it on: Mac OSX, Sun OS and Linux (and it runs
on nearly every Unix flavor thanks to mad C).
Regards,
Förster vom Silberwald
PS: One of the biggiest drawback relating to Bigloo: the interpreter is
not necessarily everyones darling and is very limited. Bigloo should be
really exclusively used for the sake of steering a sole Scheme compiler.
From: Duane Rettig
Subject: Re: Newbie: help me with choosing a Lisp implementation
Date:
Message-ID: <4is64gv99.fsf@franz.com>
"F�rster vom Silberwald" <··········@hotmail.com> writes:
> Gareth McCaughan wrote:
>
> > If you read what I wrote as saying "Bigloo is not being
> > actively developed" then I was unclear; I certainly did
> > not mean to imply anything of the sort.
>
> As I said I didn't beliebe you have drawn your conclusions from the
> activity on the Bigloo list; which is quite low by the way.
>
> However, I cannot resist: comp.lang.lisp.franz has zero messages since
> 2005 (at least on my Google). I hope I am not heading in the wrong
> direction when I believe that "Franz" is somehow related to Alegro
> Common Lisp. So Alegro Common Lisp is dead - right?
comp.lang.lisp.franz is not at all related to Franz Inc's Allegro CL.
Its stated purpose is for the discussion of Franz Lisp, which is a
different lisp which _is_ for the most part dead (though a few
apparently still use it). Franz Inc got its start enhancing and
selling Franz Lisp in 1984, but quickly moved on to create and sell
Allegro CL and eventually phased out Franz Lisp sales.
So the conclusions which Gareth didn't draw are still valid :-)
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig wrote:
> comp.lang.lisp.franz is not at all related to Franz Inc's Allegro CL.
> Its stated purpose is for the discussion of Franz Lisp, which is a
> different lisp which _is_ for the most part dead (though a few
> apparently still use it). Franz Inc got its start enhancing and
> selling Franz Lisp in 1984, but quickly moved on to create and sell
> Allegro CL and eventually phased out Franz Lisp sales.
But I can't remember a franzlisp-related question on that list in many
years. It seems its only function is to catch spam and misdirect an
occasional newbie to ask Common Lisp questions there.
Can anyone else remember any recent appropriate messages there?
Perhaps it is time to try to get the group expunged. Thet used
to be possible in ancient Usenet days, but I'm unclear on current
procedures.