Commit e5a65341 authored by Erik Huelsmann's avatar Erik Huelsmann
Browse files

Initial import

parents
Pipeline #3494 passed with stage
in 2 seconds
pages:
stage: deploy
script:
- mkdir .public
- mv * .public
- mv .public public
artifacts:
paths:
- public
tags:
- site-gen
only:
- master
{\rtf1\mac\ansicpg10000\cocoartf824\cocoasubrtf410
{\fonttbl\f0\fswiss\fcharset77 Helvetica;}
{\colortbl;\red255\green255\blue255;}
\paperw11900\paperh16840\margl1440\margr1440\vieww12360\viewh14240\viewkind0
\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\ql\qnatural\pardirnatural
\f0\fs24 \cf0 Common Lisp Document Repository (CDR)\
\
\
* What\
\
The Common Lisp Document Repository is a repository of documents that are of interest to the Common Lisp community. The most important property of a CDR document is that it will never change: if you refer to it, you can be sure that your reference will always refer to exactly the same document.\
\
\
* Why\
\
There have been a number of attempts to establish a standardization process for Common Lisp after it has been officially published as an ANSI standard. The ANSI standardization was very costly and very time consuming (according to http://groups.google.com/group/comp.lang.lisp/msg/15248a1b11c5a603 it took nearly 10 years and at least $400K).\
\
The goal of the Common Lisp Document Repository is to be more light-weight and more efficient. We focus on one aspect of standardization: the ability to refer to a specification document in an unambiguous way.\
\
The Common Lisp Document Repository intentionally does not define a process for coming up with specifications or any other means to guarantee some level of quality of the submitted documents. Instead, we aim for a community-driven, decentralized approach to come up, discuss and finalize specifications. In this sense, we only provide the services of librarians.\
\
We hope that the Common Lisp Document Repository has the potential to prove useful in establishing new de-facto standards, and to serve as a stepping stone for more formal standardizations in the long run.\
\
\
* Where\
\
The Common Lisp Document Repository is hosted at http://cdr.eurolisp.org.\
\
* How\
\
\pard\tx566\tx1133\tx1700\tx2267\tx2834\tx3401\tx3968\tx4535\tx5102\tx5669\tx6236\tx6803\ql\qnatural\pardirnatural
\cf0 The Common Lisp Document Repository is a repository of printable text documents that contain material that are of interest to the Common Lisp community. For example, a CDR document can contain specifications of libraries, language extensions, example implementations, test suites, articles, etc. Each CDR document will be identified by a number. Form and possible contents of CDR documents are not prescribed, but the goal is to provide the Common Lisp community with a way to unambiguously refer to a document by way of mentioning its CDR number. The presence of a document in the CDR repository does not imply a recommendation of any kind, but we leave the acceptance or rejection of particular documents to the community's natural selection process. We expect that some CDR documents will claim to be replacements of, or clarifications for, previous ones, but again such statements do not mean that this repository's goal is to enforce such developments. We are just librarians who want to make it possible to refer and cite documents of interest to Common Lispers.\
\
We use a light-weight process that consists of the following steps:\
\
1. One or more authors submit a document.\
\
2. We check that the document is a printable text document, that it is indeed about Common Lisp, and that it does not contain objectionable material (like porn, religious or political statements, etc.).\
\
3. The document will be immediately assigned a fresh CDR number that can be used to refer to the document. We will make the document available for an initial period, after which it will be frozen and moved into final status, unless the authors decide to withdraw the document during the initial period.\
\
For more details about the process, see the manual below.\
\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\ql\qnatural\pardirnatural
\cf0 \
\
* Manual\
\
\pard\tx566\tx1133\tx1700\tx2267\tx2834\tx3401\tx3968\tx4535\tx5102\tx5669\tx6236\tx6803\ql\qnatural\pardirnatural
\cf0 The CDR Process\
\
1. Submit your document. It should be in a widely used format, like PostScript, PDF, etc. We will check the printability of your document with common current readers. If we cannot print the document, we will ask you to resubmit.\
\
2. Convince us that we have the right to make the document publicly available. The easiest is if you are the author and give us the (non-exclusive) publishing rights, or if the document has a free license for documents, like the GNU Free Documentation License or a Creative Commons license, or something similar. (The license should, however, not affect any other material at the CDR website.) We do not want to exclude the possibility of publishing the CDR repository in other forms, like on CD-ROMs or DVDs, etc. So make sure that the publishing rights are not restricted to the CDR website.\
\
3. We will make the document and any accompanying material (see below) available at the CDR website, under a fresh CDR number that has not been used for any other CDR document before. There will be an initial period of six weeks in which you can send us updated versions, for example to correct typos, etc., which will replace any older version with the same CDR number. You can negotiate with us a longer initial period, but the maximum length is one year. After the initial period, we will freeze the last version of the document and any accompanying material, move it into final status and provide this version from then on as part of the CDR repository, unless you decide that you withdraw the document, in which case we will only provide the title of the document and indicate its withdrawn status for the records.\
\
We reserve the right to reject documents when they are not clearly related to Common Lisp, or contain objectionable material, including in its accompanying material. We also reserve the right to withdraw documents and their accompanying material from the repository in case there are doubts with regard to copyrights. Our priority here is to avoid legal issues that have any negative impact on us as publishers.\
\
\
You are encouraged, but not required to:\
\
- Discuss your document publicly before you submit it as a CDR document, for example in mailing lists, newsgroups, or other public forums.\
\
- Provide an archive of the discussions that influenced the contents of the CDR document that we can publish as accompanying material alongside the document itself.\
\
- Provide an abstract of the document that we can use on the website so that readers get a better idea what to expect from the document.\
\
- Provide a rationale as part of the document why it is related to, and/or important for, Common Lisp.\
\
- Use an established structure for the contents of a document, like for example the structure used for issues that accompany the ANSI Common Lisp specification.\
\
- Provide the sources for the document, in case it is generated using, for example, a document preparation system like LaTeX.\
\
- Provide contact email address(es) and/or website URL(s) for further information about the specific document. Email addresses and website URLs can always be updated, including for CDR documents in final status.\
\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\ql\qnatural\pardirnatural
\cf0 \
\
\
- How do I submit a document?\
\
Send it to editors@cdr.eurolisp.org. There can be a delay before we react to a submission, but typically we should react promptly. If you don't hear from us within 7 days, bug us. Our first reaction will contain:\
\
1) An assessment whether we accept the document for publication or not.\
\
In case we accept the document, our reaction will also contain:\
\
2) A fresh CDR number that can be used to refer to the submitted document.\
3) A URL where the document is published.\
4) A deadline when the initial period for this document ends (usually after 6 weeks).\
\
We will also announce the submission of the new document, for example in mailing lists, newsgroups and/or in other appropriate ways.\
\
- How do I refer to a document? \
\
A CDR document has a unique number. You can refer to it by mentioning that number. Assuming the number of a CDR document is 42, ways to refer to that document include, but are not limited to, "CDR document 42", "CDR 42" and "document 42 in the Common Lisp Document Repository". A URL of the form "http://cdr.eurolisp.org/document/NNN" (for example "http://cdr.eurolisp.org/document/42" for document 42) can be used to refer to the document as well.\
\
- How do I change a document?\
\
During the initial period (usually 6 weeks) after a document has been submitted for the first time, the document can be resubmitted in a changed form any time by sending it to editors@cdr.eurolisp.org. Afterwards, a document cannot be changed anymore. Under exceptional circumstances, prolongation of the initial period can be negotiated.\
\
- How do I remove a document?\
\
During the initial period (usually 6 weeks) after a document has been submitted, the document can be removed by the authors at any time by sending a request to editors@cdr.eurolisp.org. Afterwards, a document can only be removed under exceptional circumstances. When a document is removed the repository will show the title of the document and indicate its withdrawn status for the records.\
\
\
Marc Battyani, Pascal Costanza, Arthur Lemmens, Edmund Weitz\
}
\ No newline at end of file
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html> <head>
<title>CDR 0: Common Lisp Document Repository</title>
</head>
<body>
<h1>CDR 0: Common Lisp Document Repository</h1>
<h2>Authors</h2>
<p>Marc Battyani, Pascal Costanza, Arthur Lemmens, Edi Weitz</p>
<h2>Submitter</h2>
<p>Pascal Costanza, for contact use <a href=mailto:editors@cdr.eurolisp.org>editors@cdr.eurolisp.org</a></p>
<h2>Abstract</h2>
<p>The Common Lisp Document Repository is a repository of documents that are of interest to the Common Lisp community. The most important property of a CDR document is that it will never change: if you refer to it, you can be sure that your reference will always refer to exactly the same document.</p>
<h2>Rationale</h2>
<p>There have been a number of attempts to establish a standardization process for Common Lisp after it has been officially published as an ANSI standard. The ANSI standardization was very costly and very time consuming (according to <a href=http://groups.google.com/group/comp.lang.lisp/msg/15248a1b11c5a603>http://groups.google.com/group/comp.lang.lisp/msg/15248a1b11c5a603</a> it took nearly 10 years and at least $400K).</p>
<p>The goal of the Common Lisp Document Repository is to be more light-weight and more efficient. We focus on one aspect of standardization: the ability to refer to a specification document in an unambiguous way.</p>
<p>The Common Lisp Document Repository intentionally does not define a process for coming up with specifications or any other means to guarantee some level of quality of the submitted documents. Instead, we aim for a community-driven, decentralized approach to come up, discuss and finalize specifications. In this sense, we only provide the services of librarians.</p>
<p>We hope that the Common Lisp Document Repository has the potential to prove useful in establishing new de-facto standards, and to serve as a stepping stone for more formal standardizations in the long run.</p>
<h2>The Document</h2>
<ul>
<li><a href=CDR.rtf>.rtf</a></li>
<li><a href=CDR.pdf>.pdf</a></li>
</ul>
<h2>Status</h2>
<p><a href="../../final.html">Final</a></p>
<h2>See also</h2>
<p><a href="../4/index.html">CDR 4: The Common Lisp Document Repository (revised)</a></p>
<hr>
<p>
<a href="../../index.html">CDR - Common Lisp Document Repository</a><br/>
<a href="../../editors.html">The CDR Editors</a><br/>
This page last modified: November 19, 2006</p>
</body> </html>
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html> <head>
<title>CDR 1: The CLOS Metaobject Protocol</title>
</head>
<body>
<h1>CDR 1: The CLOS Metaobject Protocol</h1>
<h2>Authors</h2>
<p>Gregor Kiczales, Jim des Rivi&egrave;res, Daniel G. Bobrow</p>
<h2>Submitter</h2>
<p><a href=mailto:pc@p-cos.net>Pascal Costanza</a></h2>
<h2>Abstract</h2>
<p>The CLOS Specification describes the standard Programmer Interface for the Common Lisp Object System (CLOS). This document extends that specification by defining a metaobject protocol for CLOS - that is, a description of CLOS itself as an extensible CLOS program. In this description, the fundamental elements of CLOS programs (classes, slot definitions, generic functions, methods, specializers and method combinations) are represented by first-class objects. The behavior of CLOS is provided by these objects, or, more precisely, by methods specialized to the classes of these objects.</p>
<p>Because these objects represent pieces of CLOS programs, and because their behavior provides the behavior of the CLOS language itself, they are considered meta-level objects or metaobjects. The protocol followed by the metaobjects to provide the behavior of CLOS is called the CLOS Metaobject Protocol (MOP).</p>
<h2>Rationale</h2>
<p>We provide the detailed specification of a metaobject protocol for CLOS. Our work with this protocol has always been rooted in our own implementation of CLOS, PCL. This has made it possible for us to have a user community, which in turn has provided us with feedback on this protocol as it has evolved. As a result, much of the design presented here is well-tested and stable. As this is being written, those parts have been implemented not only in PCL, but in at least three other CLOS implementations we know of. Other parts of the protocol, even though they have been implemented in one form or another in PCL and other implementations, are less well worked out. Work remains to improve not only the ease of use of these protocols, but also the balance they provide between user extensibility and implementor freedom.</p>
<p>In preparing this specification, it is our hope that it will provide a basis for the users and implementors who wish to work with a metaobject protocol for CLOS. This document should not be construed as any sort of final word or standard, but rather only as documentation of what has been done so far. We look forward to seeing the improvements, both small and large, which we hope this publication will catalyze.</p>
<h2>The Document</h2>
<ul>
<li><a href=spec.ps.Z>.ps.Z</a></li>
<li><a href=spec.pdf>.pdf</a></li>
<li><a href=spec.tar.Z>.tar.Z</a> (TeX sources)</li>
</ul>
<h2>Accompanying Material</h2>
<ul>
<li><a href=archive.tar.gz>Archives of the original discussions about CLOS standardization and CLOS MOP specification.</a></li>
<li><a href=http://www.lisp.org/mop>The CLOS MOP specification in HTML</a> (not part of the CDR repository)</li>
</ul>
<h2>Status</h2>
<p><a href="../../final.html">Final</a></p>
<hr>
<p>
<a href="../../index.html">CDR - Common Lisp Document Repository</a><br/>
<a href="../../editors.html">The CDR Editors</a><br/>
This page last modified: November 19, 2006</p>
</body> </html>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xml:lang="en" xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Functions COMPILED-FILE-P and ABI-VERSION</title>
<meta name="author" value="Sam Steingold"/>
</head>
<body>
<h1>Functions <code>COMPILED-FILE-P</code>
and <code>ABI-VERSION</code></h1>
<h2>Author</h2>
<p>Sam Steingold</p>
<h2>Related</h2>
<p>ANSI Common Lisp standard function <code>compile-file</code>.</p>
<h2>Abstract</h2>
<p>A facility to determine whether a file is a valid compiled file for
the specific implementation and to identify the current compiled file
format.</p>
<h2>Rationale</h2>
<p>Build tools, like <code>defsystem</code> or <code>asdf</code>,
have to determine whether a file needs to be recompiled.</p>
<p>Obviously, when the compiled file is older than the
source file, recompilation is in order.</p>
<p>Alas, there are other situations when this might be necessary, e.g.,
when the implementation changes the compiled file format or when two
implementations use the same name for their compiled files
(<code>.fasl</code> is used by both <code>SBCL</code> and <code>ACL</code>).</p>
<p>Traditionally, system definition facilities have taken the route of
creating a separate directory for each combination of implementation
type, version, operating system, and architecture. This is wasteful
because the the compiled file format does not necessarily change between
versions and does not even have to depend on OS and architecture.</p>
<p>The proposed functions will simplify the build directory tree
structure and reduce the number of binary distribution bundles.</p>
<h3>Current Practice</h3>
<p>Implementation-dependent.</p>
<h3>Cost of adoption</h3>
<p>For <code>COMPILED-FILE-P</code>, probably tiny: an implementation
must be able to check for compiled file validity, so all it takes is to
export the necessary functionality, e.g.:</p>
<pre id="compiled-file-p-clisp">
#+clisp
(defun compiled-file-p (file-name)
(with-open-file (in file-name :direction :input :if-does-not-exist nil)
(and in (char= #\( (peek-char nil in))
(let ((form (ignore-errors (read in nil nil))))
(and (consp form)
(eq (car form) 'SYSTEM::VERSION)
(null (nth-value 1 (ignore-errors (eval form)))))))))
</pre>
<p>For <code>ABI-VERSION</code>, it probably depends on the
implementation; for some it might be trivial:</p>
<pre id="abi-version-clisp">
#+clisp
(defun abi-version (&amp;-optional (object nil supplied-p))
(if supplied-p
(handler-case (progn (system::version (list object)) t)
(error (e) nil))
(car (system::version))))
</pre>
<p>and for others it might not.</p>
<h3>Cost of non-adoption</h3>
<p>Users will suffer random errors when trying to load invalid binary
files.</p>
<h2>Specification</h2>
<h3>Function <code>COMPILED-FILE-P</code></h3>
<p>Function</p><pre>
(compiled-file-p file-name) ==&gt; valid-p
</pre>
<p>Returns</p><dl>
<dt><code>true</code></dt><dd>if the file appears to be a valid compiled file
(i.e., exists, is readable, and the contents appears to be
valid for this implementation),</dd>
<dt><code>false</code></dt><dd>otherwise.</dd></dl>
<p>Implementations are required to inspect the contents
(e.g., checking just the pathname type is not sufficient).
Although the completeness of the inspection is not required,
this function should be able to detect,
e.g., file format changes between versions.</p>
<h4>Exceptional situations</h4> <ul>
<li>Signals an error of type <code>type-error</code>
when the argument is not a <em>pathname designator</em>.</li>
</ul>
<h4>Examples</h4>
<pre>
(compiled-file-p "foo.lisp") ==&gt; NIL
(compiled-file-p (compile-file "foo.lisp")) ==&gt; T
</pre>
<h3>Function <code>ABI-VERSION</code></h3>
<p>Function</p><pre>
(abi-version &amp;optional object) ==&gt; object
</pre><p>identifies the ABI (Application Binary Interface) of the
presently used Common Lisp implementation.</p>
<p>When called without arguments, returns an implementation-defined
object which uniquely identifies the compiled file format
<em>produced</em> by the implementation.</p>
<p>The return <em>value</em> must satisfy three conditions:</p><ol>
<li><code>(princ-to-string value)</code> must be a valid logical
pathname component</li>
<li><code>(equalp value (let ((*package* (find-package "KEYWORD")))
(read-from-string (princ-to-string value))))</code> must be true</li>
<li>If <code>(equalp a b)</code> is true, then <code>(abi-version
a)</code> and <code>(abi-version b)</code> should either both be true,
or both be false</li>
</ol>
<p>which guarantee that it can be used to name directories where the
compiled files are stored and the ABI version can be recovered from
a directory name.</p>
<p>When called with an argument, returns a generalized boolean:</p><dl>
<dt><code>true</code></dt><dd>if the argument identifies an ABI version
which can be <em>consumed</em> by this implementation version,</dd>
<dt><code>false</code></dt><dd>otherwise.</dd></dl>
<h4 id="exeptions">Exceptional situations</h4> <ul>
<li>May signal an error of type <code>type-error</code>
when the argument is not a valid ABI version name for this implementation.</li>
</ul>
<h4>Examples</h4>
<pre>
(abi-version (abi-version))
==&gt; T
;; in clisp 2.49:
(abi-version)
==&gt; 20080430
(abi-version 20080430)
==&gt; T
(abi-version "foo")
==&gt; NIL
;; in a hypothetical lisp implementation MyCL v7 with a native compiler:
(abi-version)
==&gt; :x86_64-7 ; or, say, 64007.
(abi-version :x86_64-7)
==&gt; T
(abi-version :x86_64-6)
==&gt; T ; if files compiled by v6 are acceptable for v7
(abi-version :x86_64-8)
==&gt; NIL ; since forward compatibility cannot be assumed
(abi-version :sparc-7)
==&gt; NIL ; since native compilation is usually architecture-dependent
(abi-version "bar")
==&gt; NIL
(compile-file "foo.lisp" :output-file
(make-pathname :directory
(list (lisp-implementation-type) (princ-to-string (abi-version)))))
==&gt; #P"CLISP/20080430/foo.fas" ; or
==&gt; #P"MyCL/x86_64-7/foo.fasl"
</pre>
<h2>Reference Implementation</h2>
<p>See <a href="#compiled-file-p-clisp">above</a>.</p>
<h2>History</h2>
<p>The <code>compiled-file-p</code> spec was accepted
as <strong>CLRFI-2</strong> (in 2004).</p>
<h2>Notes</h2>
<p>The trivial implementation:</p>
<pre>
(defun compiled-file-p (file-name)
(not (nth-value 1 (ignore-errors (load file-name)))))
</pre>
<p>is wrong because,</p>
<ol>
<li><code>load</code> may fail even though the file is valid:
even when <code>foo.lisp</code> contains calls to <code>error</code>,<pre>
(compiled-file-p (compile-file "foo.lisp"))
</pre>should still return <code>T</code>.</li>
<li>this is not side-effect-free, i.e., this may define new functions and
macros (or, worse yet, redefine some existing functions and macros or
execute some malicious code).</li></ol>
<p>If we could require <code>(abi-version file)</code> to return either
the abi-version of the implementation which produced the compiled
file, or nil if the <em>file</em> is not a compiled file for this
implementation, then we could define</p><pre>
(defun compiled-file-p (file) (equalp (abi-version) (abi-version file)))
</pre><p>however, it is not obvious that all implementation can
actually do this without unwelcome invasive changes.</p>
<h2>Copying and License</h2>
<p>This work may be distributed and/or modified under the conditions of the
<a href="http://www.latex-project.org/lppl.txt">LaTeX Project Public
License</a> (LPPL), either version 1.3 or (at your option) any later
version.</p>
<p>This work has the LPPL maintenance status <em>maintained</em>.</p>
<p>The Current Maintainer of this work is Sam Steingold.</p>
</body>
</html>
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html> <head>
<title>CDR 10: Functions COMPILED-FILE-P and ABI-VERSION</title>
</head>
<body>
<h1>CDR 10: Functions <code>COMPILED-FILE-P</code> and <code>ABI-VERSION</code></h1>
<h2>Author / Submitter</h2>
<p>Sam Steingold</p>
<h2>Abstract</h2>
<p>A facility to determine whether a file is a valid compiled file for
the specific implementation and to identify the current compiled file
format.</p>
<h2>Rationale</h2>
<p>Build tools, like <code>defsystem</code> or <code>asdf</code>,
have to determine whether a file needs to be recompiled.</p>
<p>Obviously, when the compiled file is older than the
source file, recompilation is in order.</p>
<p>Alas, there are other situations when this might be necessary, e.g.,
when the implementation changes the compiled file format or when two
implementations use the same name for their compiled files
(<code>.fasl</code> is used by both <code>SBCL</code> and <code>ACL</code>).</p>
<p>Traditionally, system definition facilities have taken the route of
creating a separate directory for each combination of implementation
type, version, operating system, and architecture. This is wasteful
because the the compiled file format does not necessarily change between
versions and does not even have to depend on OS and architecture.</p>
<p>The proposed functions will simplify the build directory tree
structure and reduce the number of binary distribution bundles.</p>
<h2>The Document</h2>
<ul>
<li><a href=compiled-file-p.html>.html</a></li>
</ul>
<!--
<h2>Accompanying Material</h2>
<ul>
</ul>
-->
<!--
<h2>Changes</h2>
<ul>
</ul>
-->
<h2>Status</h2>
<p><a href="../../final.html">Final</a></p>
<!--
<h2>Previous Versions</h2>
<ul>
</ul>
-->
<hr>
<p>
<a href="../../index.html">CDR - Common Lisp Document Repository</a><br/>
<a href="../../editors.html">The CDR Editors</a><br/>
This page last modified: July 8, 2012</p>
</body> </html>
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html> <head>
<title>CDR 11: Standard output streams default behavior in terminal sessions</title>
</head>
<body>
<h1>CDR 11: Standard output streams default behavior in terminal sessions</h1>
<h2>Author / Submitter</h2>
<p>Didier Verna</p>
<h2>Abstract / Rationale </h2>
<p>The Common Lisp standard mandates the existence of several streams such as *STANDARD-OUTPUT*, *ERROR-OUTPUT* and *QUERY-IO*. The purpose of these streams, however, is only informally described, leading to implementation-specific behavior.</p>
<p>This can be problematic for Lisp sessions started from a terminal (without a graphical user interface) and standalone command-line executables. The current behavior of some standard output streams, notably with respect to shell redirection may not only be different across implementations, but also contrary to the user's expectations.</p>
<p>The purpose of this document is hence to illustrate the problem and suggest that all Common Lisp implementations agree on one particular scheme.</p>
<h2>The Document</h2>
<ul>
<li><a href=verna.12.cdr11.html>.html</a></li>
<li><a href=verna.12.cdr11.pdf>.pdf</a></li>
<li><a href=verna.12.cdr11.txt>.txt</a></li>
</ul>
<h2>Accompanying Material</h2>
<ul>
<li><a href=verna.12.cdr11.tar.gz>Sources for the document</a></li>
</ul>
<!--
<h2>Changes</h2>
<ul>
</ul>
-->
<h2>Status</h2>
<p><a href="../../final.html">Final</a></p>
<!--
<h2>Previous Versions</h2>
<ul>
</ul>
-->
<hr>
<p>
<a href="../../index.html">CDR - Common Lisp Document Repository</a><br/>
<a href="../../editors.html">The CDR Editors</a><br/>
This page last modified: July 15, 2012</p>
</body> </html>
<html lang="en">
<head>
<title>Standard output streams default behavior in terminal sessions</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="description" content="A proposal for unifying the way Common Lisp standard output streams
behave initially in terminal-based sessions. This document appears in
the Common Document Repository as CDR 11.">
<meta name="generator" content="makeinfo 4.8">
<link title="Top" rel="top" href="#Top">
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
<!--
Copyright (C) 2012 Didier Verna
Permission is granted to make and distribute verbatim copies of
this manual provided the copyright notice and this permission
notice are preserved on all copies.
Permission is granted to copy and distribute modified versions of
this manual under the conditions for verbatim copying, provided
also that the section entitled ``Copying'' is included exactly as
in the original.
Permission is granted to copy and distribute translations of this
manual into another language, under the above conditions for