~ chicken-core (chicken-5) 54005772bed76db5f22d85219db3332a33fa3387
commit 54005772bed76db5f22d85219db3332a33fa3387
Author: felix <felix@call-with-current-continuation.org>
AuthorDate: Wed Jun 4 21:43:53 2014 +0200
Commit: felix <felix@call-with-current-continuation.org>
CommitDate: Wed Jun 4 21:43:53 2014 +0200
Manual fixes and slight rewordings.
diff --git a/manual/Getting started b/manual/Getting started
index 00bd8c22..1837b8ea 100644
--- a/manual/Getting started
+++ b/manual/Getting started
@@ -172,8 +172,7 @@ communication.
=== Installing CHICKEN
-CHICKEN is available in binary form for Windows and Linux/x86
-systems, and in source form for all other platforms. Refer to the
+CHICKEN is available as C sources. Refer to the
{{README}} file in the distribution for instructions on installing it
on your system.
@@ -185,21 +184,21 @@ can pretty much ignore the C compiler once you have installed it.)
installed as part of the basic operating system, or should be
available through the package management system (e.g., APT,
Synaptic, RPM, or Yum, depending upon your Linux distribution).
-* On Macintosh OS X, you will need the XCode tools, which are shipped
- on the OS X DVD with recent versions of the operating system.
-* On Windows, you have three choices.
+* On Macintosh OS X, you will need the XCode tools, which you can download
+ at the Apple website.
+* On Windows, you have three choices:
** Cygwin ([[http://sourceware.org/cygwin/]]) provides a relatively
full-featured Unix environment for Windows. CHICKEN works
substantially the same in Cygwin and Unix.
** The GNU Compiler Collection has been ported to Windows, in the
MinGW system ([[http://mingw.sourceforge.net]]). Unlike Cygwin,
executables produced with MinGW do not need the Cygwin DLLs in order
- to run. MSys is a companion package to MinGW; it provides a minimum
+ to run. MSYS is a companion package to MinGW; it provides a minimum
Unix-style development/build environment, again ported from free
software.
*** You can build CHICKEN either with MinGW alone or with MinGW plus
MSYS. Both approaches produce a CHICKEN built against the mingw headers
- and import libraries.
+ and libraries.
The only difference is the environment where you actually run make.
{{Makefile.mingw}} is can be used in {{cmd.exe}} with the version of make
that comes with mingw. {{Makefile.mingw-msys}}
diff --git a/manual/Non-standard macros and special forms b/manual/Non-standard macros and special forms
index 087c1f10..498592e4 100644
--- a/manual/Non-standard macros and special forms
+++ b/manual/Non-standard macros and special forms
@@ -6,6 +6,20 @@
=== Making extra libraries and extensions available
+==== require-extension
+
+<macro>(require-extension ID ...)</macro>
+
+This is equivalent to {{(require-library ID ...)}} but performs an implicit
+{{import}}, if necessary. Since version 4.4.0, {{ID}} may also be an import specification
+(using {{rename}}, {{only}}, {{except}} or {{prefix}}).
+
+To make long matters short - just use {{require-extension}} and it will normally figure everything out for dynamically
+loadable extensions and core library units.
+
+This implementation of {{require-extension}} is compliant with [[http://srfi.schemers.org/srfi-55/srfi-55.html|SRFI-55]]
+(see the [[http://srfi.schemers.org/srfi-55/srfi-55.html|SRFI-55]] document for more information).
+
==== require-library
<macro>(require-library ID ...)</macro>
@@ -32,10 +46,7 @@ During compilation, one of the following happens instead:
* If {{ID}} names an installed extension with the {{syntax}} or {{require-at-runtime}} attribute, then the extension is loaded at compile-time, and code is emitted to {{(require ...)}} any needed run-time requirements.
* Otherwise {{(require-library ID)}} is equivalent to {{(require 'ID)}}.
-To make long matters short - just use {{require-library}} and it will normally figure everything out for dynamically
-loadable extensions and core library units.
-
-{{ID}} should be a pure extension name and should not contain any path prefixes (for example {{dir/lib...}}) is illegal).
+{{ID}} should be a pure extension name and should not contain any path prefixes (for example {{dir/lib...}} is illegal).
{{ID}} may also be a list that designates an extension-specifier. Currently the following extension specifiers are
defined:
@@ -43,17 +54,6 @@ defined:
* {{(srfi NUMBER ...)}} is required for SRFI-55 compatibility and is fully implemented
* {{(version ID NUMBER)}} is equivalent to {{ID}}, but checks at compile-time whether the extension named {{ID}} is installed and whether its version is equal or higher than {{NUMBER}}. {{NUMBER}} may be a string or a number, the comparison is done lexicographically (using {{string>=?}}).
-==== require-extension
-
-<macro>(require-extension ID ...)</macro>
-
-This is equivalent to {{(require-library ID ...)}} but performs an implicit
-{{import}}, if necessary. Since version 4.4.0, {{ID}} may also be an import specification
-(using {{rename}}, {{only}}, {{except}} or {{prefix}}).
-
-This implementation of {{require-extension}} is compliant with [[http://srfi.schemers.org/srfi-55/srfi-55.html|SRFI-55]]
-(see the [[http://srfi.schemers.org/srfi-55/srfi-55.html|SRFI-55]] document for more information).
-
==== use
<macro>(use ID ...)</macro>
@@ -123,8 +123,8 @@ For more information see the documentation for
<macro> (let-optionals ARGS ((VAR1 DEFAULT1) ...) BODY ...)</macro>
-Binding constructs for optional procedure arguments. {{ARGS}} should
-be a rest-parameter taken from a lambda-list. {{let-optionals}}
+Binding constructs for optional procedure arguments. {{ARGS}} is normally
+a rest-parameter taken from a lambda-list. {{let-optionals}}
binds {{VAR1 ...}} to available arguments in parallel, or
to {{DEFAULT1 ...}} if not enough arguments were provided.
{{let-optionals*}} binds {{VAR1 ...}} sequentially, so every
@@ -140,8 +140,8 @@ arguments are provided.
<macro> (let-optionals* ARGS ((VAR1 DEFAULT1) ... [RESTVAR]) BODY ...)</macro>
-Binding constructs for optional procedure arguments. {{ARGS}} should
-be a rest-parameter taken from a lambda-list. {{let-optionals}}
+Binding constructs for optional procedure arguments. {{ARGS}} is normally
+a rest-parameter taken from a lambda-list. {{let-optionals}}
binds {{VAR1 ...}} to available arguments in parallel, or
to {{DEFAULT1 ...}} if not enough arguments were provided.
{{let-optionals*}} binds {{VAR1 ...}} sequentially, so every
@@ -161,7 +161,7 @@ an error if any excess arguments are provided.
<macro>(and-let* (BINDING ...) EXP1 EXP2 ...)</macro>
-SRFI-2. Bind sequentially and execute body. {{BINDING}} can
+Bind sequentially and execute body. {{BINDING}} can
be a list of a variable and an expression, a list with a single
expression, or a single variable. If the value of an expression
bound to a variable is {{#f}}, the {{and-let*}} form
@@ -283,7 +283,7 @@ variables.
<macro>(define-constant NAME CONST)</macro>
-Define a variable with a constant value, evaluated at compile-time.
+Defines a variable with a constant value, evaluated at compile-time.
Any reference to such a constant should appear textually '''after'''
its definition. This construct is equivalent to {{define}} when
evaluated or interpreted. Constant definitions should only appear at
@@ -541,7 +541,7 @@ In addition the following feature-identifiers may exist: {{cross-chicken}},
For further information, see the documentation for
[[http://srfi.schemers.org/srfi-0/srfi-0.html|SRFI-0]].
-=== {{delay-force}}
+=== delay-force
CHICKEN supports the R7RS {{delay-force}} syntax which allows for
iterative lazy algorithms to be expressed in bounded space.
diff --git a/manual/Using the compiler b/manual/Using the compiler
index cf123f7d..894e9d4e 100644
--- a/manual/Using the compiler
+++ b/manual/Using the compiler
@@ -412,12 +412,13 @@ Let's take a simple example.
% csc -t hello.scm -optimize-level 3 -output-file hello.c
Compiled to C, we get {{hello.c}}. We need the files {{chicken.h}},
-{{chicken-config.h}} and {{runtime.c}}, which contain the basic
-runtime system, plus the five basic library files {{library.c}},
-{{eval.c}}, {{expand.c}}, {{modules.c}} and {{build-version.c}}
-which contain the same functionality as the library linked into a
-plain CHICKEN-compiled application, or which is available by
-default in the interpreter, {{csi}}:
+{{chicken-config.h}}, {{build-version.c}}, {{buildtag.h}} and
+{{runtime.c}}, which contain the basic runtime system, plus the five
+basic library files {{library.c}}, {{eval.c}}, {{expand.c}},
+{{modules.c}} and {{build-version.c}} which contain the same
+functionality as the library linked into a plain CHICKEN-compiled
+application, or which is available by default in the interpreter,
+{{csi}}:
% cd /tmp
@@ -428,6 +429,7 @@ default in the interpreter, {{csi}}:
% cp $CHICKEN_BUILD/extras.c .
% cp $CHICKEN_BUILD/expand.c .
% cp $CHICKEN_BUILD/modules.c .
+ % cp $CHICKEN_BUILD/build-version.c .
% cp $CHICKEN_BUILD/chicken.h .
% cp $CHICKEN_BUILD/chicken-config.h .
% cp $CHICKEN_BUILD/buildtag.h .
@@ -440,10 +442,11 @@ Now we have all files together, and can create an tarball containing all the fil
expand.c modules.c chicken.h chicken-config.h
% gzip hello.tar
-This is naturally rather simplistic. Things like enabling dynamic loading, estimating
-the optimal stack-size and selecting supported features of the host system would need
-more configuration- and build-time support. All this can be addressed using more
-elaborate build-scripts, makefiles or by using autoconf/automake.
+This is naturally rather simplistic. Things like enabling dynamic
+loading and selecting supported features of the host system would need
+more configuration- and build-time support. All this can be addressed
+using more elaborate build-scripts, makefiles or by using
+autoconf/automake.
The {{chicken-config.h}} file may contain wrong settings for your
deployment target. Especially when the architecture is different.
Trap