[cl-faq] [lispfaq commit] r22 - trunk

[codesite-noreply@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?