I'm new to Lisp and was wondering if there was a way to get to the
source code of the common lisp functions. I'm currently using clisp,
but I'm open to any variant. I'm just really used to Smalltalk where
you have access to everything. I realize it probably depends on which
lisp you use, but I think it would be nice.
"Ben" <·········@gmail.com> writes:
> I'm new to Lisp and was wondering if there was a way to get to the
> source code of the common lisp functions. I'm currently using clisp,
> but I'm open to any variant. I'm just really used to Smalltalk where
> you have access to everything. I realize it probably depends on which
> lisp you use, but I think it would be nice.
This is open source software, you have all the sources!
Check in clisp-2.38/src/
For clisp, what happens is that most of the functions are written in C.
Check the .d files, the .c are produced from the .d thru a pre-processor.
Some (notably the compiler) are written in Common Lisp though.
From emacs, you can use TAGS:
cd ; find /usr/local/src/clisp-2.38 \( -name \[#.]\?\* -prune \) \
-o \( -name \*.lisp -o -name \*.el -o -name \*.asd \
-o -name \*.h -o -name \*.c -o -name \*.d \) -print \
| etags -
M-x visit-tags-table RET ~/TAGS RET n RET
Then you can type: MEMBER M-.
to jump to the source of the clisp MEMBER function which is the member
C function in list.d
--
__Pascal Bourguignon__ http://www.informatimago.com/
Small brave carnivores
Kill pine cones and mosquitoes
Fear vacuum cleaner
"Ben" <·········@gmail.com> writes:
> I'm new to Lisp and was wondering if there was a way to get to the
> source code of the common lisp functions. I'm currently using clisp,
> but I'm open to any variant. I'm just really used to Smalltalk where
> you have access to everything. I realize it probably depends on which
> lisp you use, but I think it would be nice.
If you use SLIME and an open-source Lisp, you can find the source with
M-. but for CLISP it often won't be much help, since as Pascal pointed
out, it's mostly implemented in C-plus-a-custom-preprocessor. SBCL
and CMUCL are both implemented in Lisp, and so may be a bit more to
your liking here.
In these lisps, looking at the source to + is about as enlightening as
looking at the source to one of the primitive Smalltalk messasges.
However (at least for SBCL, maybe also for CMUCL), SLIME can find the
definitions of all the internal compiler transforms etc., which make
up a large part of the effective definition.
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
Ben wrote:
> I'm new to Lisp and was wondering if there was a way to get to the
> source code of the common lisp functions. I'm currently using clisp,
> but I'm open to any variant. I'm just really used to Smalltalk where
> you have access to everything. I realize it probably depends on which
> lisp you use, but I think it would be nice.
>
Paul Graham defines many CL functions in his book "ANSI Common Lisp".
These snippets of code are themselves written in Lisp.
A very good guide to what makes a Lisp tick is
"Lisp in Small Pieces", but
- it uses Scheme, not Common Lisp
- it is not exactly light reading
For REAL source code, you can always work yourself thru
your favourite Lisp open source implementation, but that's
a stiff order for a neophyte, I guess. It's even a stiff
order for an expert, so I'd start with the aforementioned
books.
If you want to start staring at code right away, there's
a toy Lisp from John McCarthy, Lisp's inventor, in his
seminal paper. http://www-formal.stanford.edu/jmc/
Ben schrieb:
> I'm new to Lisp and was wondering if there was a way to get to the
> source code of the common lisp functions. I'm currently using clisp,
> but I'm open to any variant. I'm just really used to Smalltalk where
> you have access to everything. I realize it probably depends on which
> lisp you use, but I think it would be nice.
The semi-standard methods to find source are:
1) use a Lisp-aware editor and type M-. when your cursor is on the
symbol.
2) call (ed 'my-function-name)
ED is actually a standard Common Lisp function.
Above should work once you have installed the source.
Many Lisp systems are coming with lots of source. Even for some
commercial implementations. MCL does. For Allegro CL you can get lots
of source.
http://www.franz.com/support/documentation/8.0/doc/installation.htm#source-install-1
On a Lisp Machine you click Meta-Mouse-L on a symbol.
Unfortunately LispWorks provides only tiny amounts of source (parts of
the Editor mostly).
Thank you all for the help. Your responses are what I was looking for.
I was suprised that so much of clisp is written in c. Paul Graham's
book "Ansi Common Lisp" is what made me wish for some true source.
I'll try cmucl and sbcl. I've rather enjoyed lisp so far. I like this
group, you are all very intelligent and give thorough informative
answers. Again THANKS!
"Ben" <·········@gmail.com> writes:
> Thank you all for the help. Your responses are what I was looking for.
> I was suprised that so much of clisp is written in c.
This is why clisp is so fast. Even when executing interpreted code
in clisp, you generally spend most of the time in COMMON-LISP
primitives written in C and compiled to native code.
> Paul Graham's
> book "Ansi Common Lisp" is what made me wish for some true source.
> I'll try cmucl and sbcl. I've rather enjoyed lisp so far. I like this
> group, you are all very intelligent and give thorough informative
> answers. Again THANKS!
--
__Pascal Bourguignon__ http://www.informatimago.com/
READ THIS BEFORE OPENING PACKAGE: According to certain suggested
versions of the Grand Unified Theory, the primary particles
constituting this product may decay to nothingness within the next
four hundred million years.
Pascal Bourguignon <···@informatimago.com> writes:
> This is why clisp is so fast. Even when executing interpreted code
> in clisp, you generally spend most of the time in COMMON-LISP
> primitives written in C and compiled to native code.
How does CLisp differ in this respect from most other Lisps, where
presumably also the CL functions are compiled?
--
Frode Vatvedt Fjeld
Frode Vatvedt Fjeld <······@cs.uit.no> writes:
> Pascal Bourguignon <···@informatimago.com> writes:
>
>> This is why clisp is so fast. Even when executing interpreted code
>> in clisp, you generally spend most of the time in COMMON-LISP
>> primitives written in C and compiled to native code.
>
> How does CLisp differ in this respect from most other Lisps, where
> presumably also the CL functions are compiled?
In nothing, but people tend to think that clisp (CL) is _slow_, just
because it contains an interpreter and a byte-compiler+vm instead of a
"native" compiler. It may be slower than SBCL, but it's fast enough
for my uses.
--
__Pascal Bourguignon__ http://www.informatimago.com/
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
Pascal Bourguignon <···@informatimago.com> writes:
> ... but people tend to think that clisp (CL) is _slow_, just
> because it contains an interpreter and a byte-compiler+vm instead of a
> "native" compiler. It may be slower than SBCL, but it's fast enough
> for my uses.
Note that CLISP, by virtue of the VM, is in theory on par with
many other language implementations that are also based on a VM plus
supporting code. E.g. Python, Emacs, Perl(?)...
In practice, each implementation will have strength and weaknesses.
If one or the other implementation is faster than another, this could
be due to (this non-exhaustive list):
- better algorithm
- better design trade-off for a particular issue
- bytecode design better suited to a particular task at hand
- less overhead for a particular operation
- better mapping from abstract (code) to concrete (execution),
e.g. built-in support for often used iteration constructs
In a similar vein, here's an informal proof why Edi Weitz CL-PPCRE is
faster than Perl at regular expressions: Typical regex engines are
implemented using a dedicated VM design for that purpose (have a look
at regex.c). Edi's code needs no such VM and directly compiles to
closures. Thus there's no interpretation overhead for VM bytecodes
when using CL-PPCRE in a Lisp that compiles to native code:
Lisp is faster (e.g. cmucl, sbcl, ...).
The same reasoning informally explains why CLISP is slower than Perl
or C using CL-PPCRE: with CLISP, there's still Lisp VM bytecode
interpretation overhead, compared to the dedicated regexp VM. Assume
the dedicated VM to be faster at its job than the other one.
Regards,
Jorg Hohle
Telekom/T-Systems Technology Center
> * Joerg Hoehle <······@hfref.fbheprsbetr.arg> [2006-05-09 11:12:13 +0200]:
>
> The same reasoning informally explains why CLISP is slower than Perl
> or C using CL-PPCRE: with CLISP, there's still Lisp VM bytecode
> interpretation overhead, compared to the dedicated regexp VM. Assume
> the dedicated VM to be faster at its job than the other one.
ISTR that CLISP+CL-PPCRE is faster for some tasks than CLISP+PCRE (PCRE
module written in C).
The reason, I think, is conversion between Lisp and C strings: PCRE
uses utf-8 while CLISP uses ucs-4 (see src/stream.d:3916).
--
Sam Steingold (http://www.podval.org/~sds) on Fedora Core release 5 (Bordeaux)
http://mideasttruth.com http://openvotingconsortium.org http://truepeace.org
http://ffii.org http://memri.org http://pmw.org.il http://camera.org
This message is rot13 encrypted (twice!); reading it violates DMCA.