From codesite-noreply at google.com Tue Jul 22 14:53:45 2008 From: codesite-noreply at google.com (codesite-noreply@google.com) Date: Tue, 22 Jul 2008 12:53:45 -0700 Subject: [cl-faq] [lispfaq commit] r21 - in trunk: . code Message-ID: <000e0cd2979e81fc720452a22e56@google.com> Author: peter.seibel Date: Tue Jul 22 12:52:39 2008 New Revision: 21 Modified: trunk/code/faq.lisp trunk/faq.txt Log: Fixing typo. Modified: trunk/code/faq.lisp ============================================================================== --- trunk/code/faq.lisp (original) +++ trunk/code/faq.lisp Tue Jul 22 12:52:39 2008 @@ -21,7 +21,8 @@ (defun render-faq (input &optional output) "Generate HTML version of FAQ." - (let ((*paragraph-tags* '("modeline"))) + (let ((*paragraph-tags* '("modeline")) + (*parse-links* nil)) (with-tag-translations ((:cl . (:span :class :cl)) (:datestamp . datestamp) (:figure . figure)) Modified: trunk/faq.txt ============================================================================== --- trunk/faq.txt (original) +++ trunk/faq.txt Tue Jul 22 12:52:39 2008 @@ -557,7 +557,7 @@ application all run within the same process. This is quite a profound difference, for example it means that your application automatically has a built in compiler! There are many different implementations of -Lisp, and what is available in your image may very - for example some +Lisp, and what is available in your image may vary - for example some Lisps have no interpreter part & some only have a compiler. I have started thinking of my Lisp image as its own environment, From codesite-noreply at google.com Tue Jul 22 17:03:49 2008 From: codesite-noreply at google.com (codesite-noreply@google.com) Date: Tue, 22 Jul 2008 15:03:49 -0700 Subject: [cl-faq] [lispfaq commit] r22 - trunk Message-ID: <0016e6de005eaf041c0452a3ffae@google.com> Author: peter.seibel Date: Tue Jul 22 15:03:11 2008 New Revision: 22 Modified: trunk/faq.txt trunk/lispfaq.txt trunk/staging-faq.txt Log: Another typo and some old unchecked in changes. Modified: trunk/faq.txt ============================================================================== --- trunk/faq.txt (original) +++ trunk/faq.txt Tue Jul 22 15:03:11 2008 @@ -545,12 +545,77 @@ *** Where is my compiler? My debugger? Where is my program running? -Lisp works quite differently than most languages that you may be -familiar with, for example C has a very distinct cycle. In the C -style, you edit some code, compile it with a separate compiler and -produce an executable. You can then run that executable, perhaps with -a debugger attached to it. Modern IDEs smooth the distinctions between -these steps, but under the hood they are still there. +When it comes to how you develop and run your software Lisp works +differently than most other languages that you may be familiar with. +(Unless you happen to be familiar with Smalltalk, which inherited many +of its ideas from Lisp.) If you are used to "compiled" languages, for +example C, C++, Java, C#, Pascal, FORTRAN, or many others, you are +familiar with the edit-compile-run cycle. You edit your code, which +lives in one or more files. Then you feed the files to a compiler, +which produce an executable. You can then run that executable, +possibly under control of a debugger. When you want to make your next +change, you quit the program (or it crashes) and you go back to +editing the code, recompile, and rerun. Modern IDEs may smooth out the +steps of this cycle but the three steps are still there under the +covers. + +In "interpreted" languages such as Perl and Python the compile phase +of the cycle is taken out--you edit your code and then feed it to an +interpreter (for example, \code{/usr/bin/perl} or +\code{/usr/bin/python}) which directly runs it. (For some definition +of "directly": internally both languages compile the text of your +program into a representation more amenable to speedy interpretation. +Conversely, in some "compiled" languages, such as Java, the output of +the compiler isn't an executable containing machine code but rather +bytecodes that can then be interpreted by another program, such as the +Java Virtual Machine. And to bring things full circle, the JVM may +"interpret" those bytecodes using a Just In Time (JIT) compiler which, +at runtime, compiles the bytecodes into actual machine code which can +then be run directly on the CPU.) + +In Lisp, on the other hand, you develop interactively--you launch a +Lisp process once and then interact with it. The core of this +interaction typically occurs at the Read-Eval-Print Loop, a.k.a. the +REPL. At the REPL, which is much like a shell in an operating system, +you can type Lisp expressions which are then \i{read} (converted from +strings to Lisp data), \i{evaluated} to produce a value, which is then +\i{printed}. Then you do it again--the \i{loop}. + +Since new variables, functions, classes and everything else in Common +Lisp are defined simply by evaluating the appropriate expressions, +everything you do in CL can be done at the REPL. (In reality, most +Lispers use slightly more sophisticated systems, such as SLIME or the +IDEs provided with commercial Common Lisps, that allow them to "send" +expressions to Lisp from files without literally cutting and pasting +them into the REPL. But the effect is the same.) + +Common Lisp also provides two functions to deal with source code saved +in files. The function \cl{LOAD} loads all the definitions from a +given file into the running Lisp, as if you had typed them at the +REPL. \cl{LOAD} also knows how to load files that are produced by the +second function, \cl{COMPILE-FILE}, which takes a file of Lisp source +code and produces a so called "fast load" or "fasl" file. The language +standard specifies certain minimum amount of "compilation" that +\cl{COMPILE-FILE} must perform (basically it has to fully expand +macros) but many implementations actually produce \code{.fasl} files +containing native machine code for the platform the Lisp is running +on. When such a file is \cl{LOAD}ed the machine code is linked into +the running Lisp process. Another way to compile code is with the +function \cl{COMPILE} which takes the name of an already defined +function (such as one defined at the REPL) and replaces it with a +compiled version. Again, what "compiled" means depends on the +implementatation. In some implementations it means compiled to machine +code; in others it might compile to bytecodes that can then be +efficiently interpreted by the Lisp, in yet others it might merely +mean the "minimal compilation" mandated by the language standard that +requires all macros to be fully expanded. Or, possibly, \cl{COMPILE} +may do nothing since the Lisp may \i{always} compile everything, +including expression typed at the REPL, so as soon as you typed a +function definition at the REPL or loaded it from a source file it was +compiled. (In theory a Common Lisp implementation could be a "pure" +interpreter that evaluates s-expressions as s-expressions but they +almost all use some intermediate representation. + With Lisp, you have a single Lisp process, what's known as a Lisp \i{image}, and the compiler, interpreter, debugger and your @@ -560,9 +625,6 @@ Lisp, and what is available in your image may vary - for example some Lisps have no interpreter part & some only have a compiler. -I have started thinking of my Lisp image as its own environment, -almost a separate little operating system. - Interacting with the Lisp image is done via the Read-Eval-Print-Loop (REPL), which as the name implies, reads input, evaluates and then prints it. You can send forms to the REPL and immediately get back the @@ -1087,7 +1149,7 @@ first-class, multiply-invocable continuations then one can build threads, exceptions, coroutines, and the kitchen sink on top. -However, such continuations present a a heavy burden for a Lisp +However, such continuations present a heavy burden for a Lisp implementer and may preclude or at least complicate other desirable optimizations. The ANSI standardizing committee decided that it would be better to specify the user-level control structure (\cl{CATCH}, Modified: trunk/lispfaq.txt ============================================================================== --- trunk/lispfaq.txt (original) +++ trunk/lispfaq.txt Tue Jul 22 15:03:11 2008 @@ -111,20 +111,6 @@ \userinput{ (write-line "Hello, World!") } *** How do I run my programme as a script, then? -*** Is Scheme a lisp? - -Scheme is a member of the greater family of Lisp languages, assuming -that is considered to include others like Dylan and Emacs Lisp. The -design of Scheme \i{predates} the ANSI Common Lisp standard, and some -CL features such as lexical scoping may be considered to have been -derived from Scheme. - -More detailed comparative discussions don't generally prove very -productive; those that are interested in discussing Scheme should -first consider discussing it in \link{\href{news:comp.lang.scheme} -\text{comp.lang.scheme}}, where discussion would be much more welcome -and appropriate. - ** Possibly obsolete Modified: trunk/staging-faq.txt ============================================================================== --- trunk/staging-faq.txt (original) +++ trunk/staging-faq.txt Tue Jul 22 15:03:11 2008 @@ -803,7 +803,19 @@ *** If Lisp is so great, why doesn't everybody use it? +** The nitty-gritty + +*** Should I use the difference between (lambda () ...) or #'(lambda () ....) + +*** When should I use EQ vs EQL? + +*** What are type declarations for? + +*** Why is there no BACKQUOTE macro or special operator for `(...) to expand into? + ** Miscellaneous + +*** It is 13 years since the CL ANSI standard and still it hasn't been revised. Are there any specific plans for it? Isn't this acting as a hampering point in such a cool programming language? *** Speaking of the standard, what should I do if I find a discrepancy between the behavior of my Lisp and the standard?