 |
Newsgroups: comp.lang.lisp
From: Rainer Joswig <jos...@lisp.de>
Date: Sun, 21 Nov 2004 10:44:55 +0100
Local: Sun, Nov 21 2004 4:44 am
Subject: Re: CL subset?
In article <10q0milmhrlj...@corp.supernews.com>,
Chris Capel <ch....@iba.nktech.net> wrote: > Rainer Joswig wrote: All Lisp systems are different. > > In article <10q035uh93d2...@corp.supernews.com>, > >> sketer...@gmail.com wrote: > >> > Other implementations might have more overhead (I > >> ~ $ ls /usr/local/lib/sbcl/sbcl.core -l > >> I don't know about you, but 23 MB for the default core seems a bit big to > > Is the file size the problem for you? Or the size of used > [snip] > > Is that 23MB SBCL core shareable if you start more than one SBCL? > Well, aside from the overcommitment of memory, which causes my process > Now, this isn't a problem for a server or a development machine or a a) Lisps that have extensive development environments, large libraries, Allegro CL, LispWorks. b) Lisps that don't have that good performance, but small footprint. OpenMCL, MCL, CLisp, Corman CL, ... c) special purpose Lisps for embedding and/or delivery. CLICC (dead), WCL (dead), ECL (actively maintained), ThinLisp d) native compiling Lisps with often excellent performance ACL, LispWorks, CMUCL, SBCL, ... e) Lisps for the Windows platform with special support Corman Lisp, Golden Common Lisp, Allegro CL for Windows, LispWorks for Windows f) Lisps for the Mac OS X platform with special support MCL, OpenMCL, LispWorks for Macintosh g) cross-platform Lisps CLisp, GCL, CMUCL, SBCL, ACL, LispWorks, ... h) Lisps for multiprocessor machines Scieneer Common Lisp, OpenMCL, Corman CL (?), ... i) 64bit Lisps Scieneer Common Lisp, Allegro CL, ... j) Lisps on top of a Lisp operating system Xerox Common Lisp, Symbolics Common Lisp, TI CL, ... and so on. Coming back to your question, yes, there are other Lisps that > I have little experience with other implementations, and now that Yes, CLISP is small. So is OpenMCL on the Mac. IIRC you can compile > I look, CLISP indeed only takes up a few megabytes in memory, most of that > shared. That's less that twice as much as bash. code with GCL to be relatively small. > Can anyone speak as to whether there are difficulties with performance when For some applications that can be advantage. Usually other Lisps will generate much faster running code. CLISP has fast bignums. > > How about ECL? CLISP? GCL? On the Mac, OpenMCL is also > > There were several Lisps that tried to be smaller and/or > But the problem with CLISP, and far worse with GCL and ECL, is the poor Plus in everyday programming not-so-perfect ANSI-CL-compliance Something not to underestimate is that applications are > I looked into GCL today, and found it The GCL is currently quite active. So it might be possible > couldn't be used in SLIME! (Though I understand the maintainers aren't > happy about this, but not exactly rolling in free-time or > listener-supported motivation :-).) that there will be something like that some time. In the meantime just use ILISP... > Now, as a target for deployment, that Sure. GCL is based on earlier Lisps that spawned a whole family > may not be such a big issue, and seeing as how GCL was based on gcc, I > thought "Hey, maybe it supports some cool embeddable things like compiling > to linkable libraries or taking out the compiler". It may be that that > would be a solution for a past problem, when machines were smaller, but > then GCL's been around for a while, hasn't it? of implementations (KCL, AKCL, GCL, ... wasn't ECL earlier also in the KCL-family?). > Now that you've pointed it out, ECL and WCL seem to be up the alley I was >While you'll find Cliki WCL is mostly dead I think. > entries for them, they aren't mentioned much in other Cliki pages. You > won't find them on many libraries' "supported" list (unless I've been > selectively blind). They aren't mentioned in blogs, they aren't mentioned > in usenet, they aren't mentioned much in #lisp. What's the reason for this? > Do they have the some sort of incompleteness/weirdness/ obseleteness? Or > maybe their users are just too happy to ever complain. :-) Maybe they have > a separate culture... ECL is active, but not that widely used I would think. > Is there a link for WCL that's more informative than http://wcl.kontiki.com/ Right. LispWorks has been used for the Regex Coach by Edi Weitz. > ? That page is rather sparse. > > Many people had that problem over the time. Some > My head hurts thinking about all these issues. That and I've been trying to > I keep hearing about Lispwork's nice deployment and GUI and stuff. The Regex This should give you an impression what a small application of LispWorks would look like. Xanalys has another application written in LispWorks: Link Explorer - which was 'Watson' in early times. (http://www.xanalys.com/solutions/linkexplorer.html). You can also do interesting applications for Windows with Allegro CL. > So, the sort of modularity I referred to in my OP is desirable, right?
> Perhaps not a top priority, and perhaps increasingly irrelevant, and > perhaps not something that will actually make it into any implementation, > but ... > Thanks for you time. > Chris Capel You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
| |||||||||||||