[lispfaq-cvs] CVS update: lispfaq/__FILE__.xml lispfaq/apply-macros.xml lispfaq/array-initialize.xml lispfaq/books.xml lispfaq/continuations.xml lispfaq/faq.xsl lispfaq/flet.xml lispfaq/freelisp.xml lispfaq/on-topic.xml lispfaq/online.xml
Eric Marsden
emarsden at common-lisp.net
Mon Mar 22 20:07:42 UTC 2004
Update of /project/lispfaq/cvsroot/lispfaq
In directory common-lisp.net:/tmp/cvs-serv16736
Modified Files:
__FILE__.xml apply-macros.xml array-initialize.xml books.xml
continuations.xml faq.xsl flet.xml freelisp.xml on-topic.xml
online.xml
Log Message:
- minor formatting changes
Date: Mon Mar 22 15:07:42 2004
Author: emarsden
Index: lispfaq/__FILE__.xml
diff -u lispfaq/__FILE__.xml:1.1 lispfaq/__FILE__.xml:1.2
--- lispfaq/__FILE__.xml:1.1 Mon Mar 22 13:55:25 2004
+++ lispfaq/__FILE__.xml Mon Mar 22 15:07:41 2004
@@ -1,31 +1,32 @@
<qandaentry>
<question>
<para>
- What is the Lisp equivalent of the __FILE__ and __LINE__ ANSI C
- preprocessor macros? How do I find out where an error occurred?
+ What is the Lisp equivalent of the <symbol>__FILE__</symbol> and
+ <symbol>__LINE__</symbol> <acronym>ANSI</acronym> C preprocessor
+ macros? How do I find out where an error occurred?
</para>
</question>
<answer>
<para>
- There is no direct equivalent of __FILE__ and __LINE__ in ANSI
- Common Lisp; this is perhaps most simply explained by the fact
- that CL is not particularly a file-oriented and definitely not
- a line-oriented language. That said, your particular
- implementation may carry around some information about where
- functions were compiled, and COMPILE-FILE binds the special
- variables *COMPILE-FILE-TRUENAME* and *COMPILE-FILE-PATHNAME*.
+ There is no direct equivalent of <symbol>__FILE__</symbol> and
+ <symbol>__LINE__</symbol> in ANSI Common Lisp; this is perhaps
+ most simply explained by the fact that CL is not particularly a
+ file-oriented and definitely not a line-oriented language. That
+ said, your particular implementation may carry around some
+ information about where functions were compiled, and
+ <code>COMPILE-FILE</code> binds the special variables
+ <code>*COMPILE-FILE-TRUENAME*</code> and
+ <code>*COMPILE-FILE-PATHNAME*</code>.
</para>
</answer>
<answer>
- <para>
+ <programlisting>
(defun foo () (break "Stopped inside ~S" (the-function-i-am-in)))
- </para>
- <para>
+
(setf (symbol-function 'bar) (symbol-function 'foo))
- </para>
- <para>
+
(bar)
- </para>
+ </programlisting>
<para>
Are you in a breakpoint in FOO or in BAR?
</para>
Index: lispfaq/apply-macros.xml
diff -u lispfaq/apply-macros.xml:1.1 lispfaq/apply-macros.xml:1.2
--- lispfaq/apply-macros.xml:1.1 Mon Mar 22 13:55:25 2004
+++ lispfaq/apply-macros.xml Mon Mar 22 15:07:41 2004
@@ -13,48 +13,43 @@
</para>
<para>
- OK, so what's the <emphasis>real</emphasis> reason? The
- reason that <function>AND</function> and
- <function>OR</function> are macros rather than functions
- is because they implement control structure in addition to
- computing a boolean value. They evaluate their subforms
- sequentially from left/top to right/bottom, and stop
- evaluating subforms as soon as the result can be
- determined (in the case of <function>AND</function>, as
+ OK, so what's the <emphasis>real</emphasis> reason? The reason
+ that <function>AND</function> and <function>OR</function> are
+ macros rather than functions is because they implement control
+ structure in addition to computing a boolean value. They
+ evaluate their subforms sequentially from left/top to
+ right/bottom, and stop evaluating subforms as soon as the result
+ can be determined (in the case of <function>AND</function>, as
soon as a subform returns NIL; in the case of
- <function>OR</function>, as soon as one returns non-NIL);
- this is referred to as "short circuiting" in computer
- language parlance. <function>APPLY</function> and
- <function>FUNCALL</function>, however, are ordinary
- functions; therefore, their arguments are evaluated
- automatically, before they are called. Thus, were
- <function>APPLY</function> able to be used with
- <function>#'AND</function>, the short-circuiting would be
- defeated.
+ <function>OR</function>, as soon as one returns non-NIL); this
+ is referred to as "short circuiting" in computer language
+ parlance. <function>APPLY</function> and
+ <function>FUNCALL</function>, however, are ordinary functions;
+ therefore, their arguments are evaluated automatically, before
+ they are called. Thus, were <function>APPLY</function> able to
+ be used with <function>#'AND</function>, the short-circuiting
+ would be defeated.
</para>
<para>
- Perhaps you don't really care about the
- short-circuiting, and simply want the functional, boolean
- interpretation. While this may be a reasonable
- interpretation of trying to apply AND or OR, it doesn't
- generalize to other macros well, so there's no obvious way
- to have the Lisp system "do the right thing" when trying
- to apply macros. The only function associated with a
+ Perhaps you don't really care about the short-circuiting, and
+ simply want the functional, boolean interpretation. While this
+ may be a reasonable interpretation of trying to apply AND or OR,
+ it doesn't generalize to other macros well, so there's no
+ obvious way to have the Lisp system "do the right thing" when
+ trying to apply macros. The only function associated with a
macro is its expander function; this function accepts and
- returns and form, so it cannot be used to compute the
- value.
+ returns and form, so it cannot be used to compute the value.
</para>
<para>
The Common Lisp functions <function>EVERY</function> and
- <function>SOME</function> can be used to get the
- functionality you intend when trying to apply
- <function>#'AND</function> and <function>#'OR</function>.
- For instance, the erroneous form:
- <userinput>(apply #'and *list*)</userinput>
- can be translated to the correct form:
- <userinput>(every #'identity *list*)</userinput>.
+ <function>SOME</function> can be used to get the functionality
+ you intend when trying to apply <function>#'AND</function> and
+ <function>#'OR</function>. For instance, the erroneous form:
+ <userinput>(apply #'and *list*)</userinput> can be translated to
+ the correct form: <userinput>(every #'identity
+ *list*)</userinput>.
</para>
</answer>
</qandaentry>
Index: lispfaq/array-initialize.xml
diff -u lispfaq/array-initialize.xml:1.1 lispfaq/array-initialize.xml:1.2
--- lispfaq/array-initialize.xml:1.1 Mon Mar 22 13:55:25 2004
+++ lispfaq/array-initialize.xml Mon Mar 22 15:07:41 2004
@@ -1,15 +1,24 @@
<qandaentry>
<question>
<para>
- I want an array of foos, but (make-array 10 :initial-element
- (make-foo)) causes strange bugs. Why?
+ I want an array of foos, but
+
+ <programlisting>
+ (make-array 10 :initial-element (make-foo))
+ </programlisting>
+
+ causes strange bugs. Why?
</para>
</question>
<answer>
<para>
Well, the array created above contains 10 pointers to the same
foo, which will indeed cause strange bugs. The correct way to
- initialize your array is probably (map-into (make-array 10) #'make-foo)
+ initialize your array is probably
+
+ <programlisting>
+ (map-into (make-array 10) #'make-foo)
+ </programlisting>
</para>
</answer>
</qandaentry>
Index: lispfaq/books.xml
diff -u lispfaq/books.xml:1.1 lispfaq/books.xml:1.2
--- lispfaq/books.xml:1.1 Mon Mar 22 13:55:25 2004
+++ lispfaq/books.xml Mon Mar 22 15:07:41 2004
@@ -1,6 +1,5 @@
<qandaentry>
<question>
- <para>What books should I read to learn more about
- lisp?</para>
+ <para>What books should I read to learn more about lisp?</para>
</question>
</qandaentry>
Index: lispfaq/continuations.xml
diff -u lispfaq/continuations.xml:1.1 lispfaq/continuations.xml:1.2
--- lispfaq/continuations.xml:1.1 Mon Mar 22 13:55:25 2004
+++ lispfaq/continuations.xml Mon Mar 22 15:07:41 2004
@@ -1,26 +1,26 @@
<qandaentry>
- <question>
- <para>Why doesn't Common Lisp have continuations?</para>
- </question>
- <answer>
- <para>
- Continuations are a great theoretical tool; if a language has
- first-class, multiply invocable continuations then one can build
- threads, exceptions, coroutines, and the kitchen sink on top.
- </para>
- <para>
- However, there is an implementation burden with continuations;
- supporting first-class, multiply invocable continuations
- complicates things tremendously for the Lisp implementor. The
- ANSI standardizing committee J13, mindful of this, took the view
- that it would be better to specify the user-level control
- structure (CATCH, UNWIND-PROTECT, and so on) and let
- implementors choose whether to build those on top of
- continuations or not.
- </para>
- <para>
- If you need to play with continuations, you should use a Scheme
- implementation.
- </para>
- </answer>
+ <question>
+ <para>Why doesn't Common Lisp have continuations?</para>
+ </question>
+ <answer>
+ <para>
+ Continuations are a great theoretical tool; if a language has
+ first-class, multiply invocable continuations then one can build
+ threads, exceptions, coroutines, and the kitchen sink on top.
+ </para>
+ <para>
+ However, there is an implementation burden with continuations;
+ supporting first-class, multiply invocable continuations
+ complicates things tremendously for the Lisp implementor. The
+ ANSI standardizing committee J13, mindful of this, took the view
+ that it would be better to specify the user-level control
+ structure (CATCH, UNWIND-PROTECT, and so on) and let
+ implementors choose whether to build those on top of
+ continuations or not.
+ </para>
+ <para>
+ If you need to play with continuations, you should use a Scheme
+ implementation.
+ </para>
+ </answer>
</qandaentry>
Index: lispfaq/faq.xsl
diff -u lispfaq/faq.xsl:1.1 lispfaq/faq.xsl:1.2
--- lispfaq/faq.xsl:1.1 Mon Mar 22 13:55:25 2004
+++ lispfaq/faq.xsl Mon Mar 22 15:07:41 2004
@@ -13,5 +13,11 @@
<xsl:param name="shade.verbatim" select="1"/>
<xsl:param name="css.decoration" select="1"/>
<xsl:param name="make.valid.html" select="1"/>
+ <xsl:param name="html.extra.head.links" select="1"/>
+ <xsl:param name="chunker.output.encoding" select="'ISO-8859-1'"/>
+
+ <xsl:template name="user.head.content">
+ <xsl:comment> generated HTML; do not edit </xsl:comment>
+ </xsl:template>
</xsl:stylesheet>
Index: lispfaq/flet.xml
diff -u lispfaq/flet.xml:1.1 lispfaq/flet.xml:1.2
--- lispfaq/flet.xml:1.1 Mon Mar 22 13:55:25 2004
+++ lispfaq/flet.xml Mon Mar 22 15:07:41 2004
@@ -1,13 +1,14 @@
<qandaentry>
<question>
- <para>Does anyone actually use flet?</para>
+ <para>Does anyone actually use <code>FLET</code>?</para>
</question>
<answer>
<para>
- This question is usually motivated by the existence of labels,
- which is a similar form for binding functions, but also allows
- mutual recursion between the functions being bound. Given
- this, it is perhaps natural to question the utility of flet.
+ This question is usually motivated by the existence of
+ <code>LABELS</code>, which is a similar form for binding
+ functions, but also allows mutual recursion between the
+ functions being bound. Given this, it is perhaps natural to
+ question the utility of <code>FLET</code>.
</para>
<para>
However, there are two reasons for using flet: one idiomatic
@@ -23,8 +24,10 @@
the behaviour of functions, for instance (a contrived example
due to Kent Pitman):
</para>
- <para>(defun square (x) (* x x))</para>
- <para>(flet ((square (x) (make-instance 'square :area (square
- x)))) ...)</para>
+ <programlisting>
+ (defun square (x) (* x x))
+
+ (flet ((square (x) (make-instance 'square :area (squarex)))) ...)
+ </programlisting>
</answer>
</qandaentry>
Index: lispfaq/freelisp.xml
diff -u lispfaq/freelisp.xml:1.1 lispfaq/freelisp.xml:1.2
--- lispfaq/freelisp.xml:1.1 Mon Mar 22 13:55:25 2004
+++ lispfaq/freelisp.xml Mon Mar 22 15:07:41 2004
@@ -4,8 +4,8 @@
</question>
<answer>
<para>
- There are a number of free (in both the `gratis' and the
- `libre' senses) lisp environments:
+ There are a number of free (in both the `gratis' and the `libre'
+ senses) lisp environments:
</para>
<variablelist>
<varlistentry>
Index: lispfaq/on-topic.xml
diff -u lispfaq/on-topic.xml:1.1 lispfaq/on-topic.xml:1.2
--- lispfaq/on-topic.xml:1.1 Mon Mar 22 13:55:25 2004
+++ lispfaq/on-topic.xml Mon Mar 22 15:07:41 2004
@@ -15,7 +15,7 @@
the history and evolution of Lisp tends also to be welcomed, or
at least tolerated; discussion of non-standard lisps (though
generally not Scheme or Emacs Lisp) is also accepted. Though
- CLOS (the Common Lisp Object System) has <ulink
+ <acronym>CLOS</acronym> (the Common Lisp Object System) has <ulink
url="news:comp.lang.lisp.clos">its own newsgroup</ulink> it is
also part of ANSI CL, and so is a valid topic for discussion.
</para>
Index: lispfaq/online.xml
diff -u lispfaq/online.xml:1.1 lispfaq/online.xml:1.2
--- lispfaq/online.xml:1.1 Mon Mar 22 13:55:25 2004
+++ lispfaq/online.xml Mon Mar 22 15:07:41 2004
@@ -21,7 +21,7 @@
</listitem>
</varlistentry>
<varlistentry>
- <term><ulink url="http://ww.telent.net/cliki/">CLiki</ulink></term>
+ <term><ulink url="http://www.cliki.net/">CLiki</ulink></term>
<listitem>
<para>An on-line Wiki-equivalent with emphasis on Free
software written in Common Lisp.</para>
More information about the Lispfaq-cvs
mailing list