Re: Reasons to choose CLISP over other free implementations

On Nov 28, 3:16 pm, Slobodan Blazeski <slobodan.blaze...@xxxxxxxxx>
wrote:
On Nov 28, 7:56 pm, Javier <javu...@xxxxxxxxx> wrote:



What are actually the reasons to choose CLISP over other free
implementations?

I believe there are some. Compared to SBCL, for example:

- Fast bignum operations.
- Fast CLOS instantiations.
- Much faster compiler speed, which is nice for big projects.
- Better memory management. SBCL (and CMUCL) tends to do not return
unallocated memory and wastes a lot of OS virtual memory.
- Better memory footprint. It just need about 4 Mb of memory at
startup.
- Better debugger. CLISP usually allows you to choose from more
options when an error occurs in the debugger.
- Better internationalization. Most messages are translated into
various languages.

What do you think about? Any more ideas?

- No threads so forget about web development.

I'm not sure I entirely agree with this, given that the Apaches most
people used until recently were also not threaded (let alone older
perl, and the way other, possibly threaded languages that still forked
an interpreter or kept a pool of them using Apache modules or fastcgi
were used to serve a grea deal of content). It is a limitation you
should be aware of though. Of course it makes clisp pretty useless
under windows for web stuff, but... well, I guess the win platform has
gotten better over the last few years. I would still hesitate to host
an important site on win.

- Using FFI will turn your application into GPLware.

Is it only the FFI? Maybe I misread things, but it seemed, at one
point, as if the CLisp interpretation of its GPL provision resembled
"The Thing That Ate Detroit". Have they reimplemented readline? Or was
I entirely mistaken in my interpretation of their statement on the
subject? At any rate, it is certainly more portable than CMUCL or
SBCL, and it does some kinds of math fast ;). Also, it was the first
CL I used that was basically compliant, so there is a nostalgia
factor. It is also a bit less of a beast when it comes to resources,
but that is not as big an issue as it was even 5 years ago.
.

Relevant Pages

  • Re: Reasons to choose CLISP over other free implementations
    ... Fast CLOS instantiations. ... Better memory management. ... SBCL tends to do not return ... Sorely missed in CLisp: Multithreading. ...
    (comp.lang.lisp)
  • Re: Object identity
    ... I see no justification for imposing a constraint that an interpretation ... why any number of instances in memory can't model the same human. ... you have described a 1:1 mapping and then claimed it not to ... for stating facts about named entities outside the computing space. ...
    (comp.object)
  • Re: Object identity
    ... I see no justification for imposing a constraint that an interpretation ... why any number of instances in memory can't model the same human. ... you have described a 1:1 mapping and then claimed it not to ... for stating facts about named entities outside the computing space. ...
    (comp.object)
  • Re: converting single to integer
    ... so taking a memory location that was defined as a single and copying it to a location that was then interpreted as long would come up with a different value than the original Single. ... moves the bits from one contiguous position in memory to another without regard for any specific interpretation of what either the source or destination memory may have. ... I'm guessing it's something like he read an array that had as its first value the number of entries. ...
    (microsoft.public.vb.general.discussion)
  • Re: Out-of-bounds nonsense
    ... pointer arithmetic within 'malloc'ed memory blocks (which naturally have no ... declared type) the only currently viable interpretation of these rules is the ... one that allows pointer arithmetics anywhere within the bounds of any continuous ... that dynamically allocated memory requires special handling. ...
    (comp.std.c)