mirror of
https://git.savannah.gnu.org/git/guile.git
synced 2025-04-29 19:30:36 +02:00
Fix typos throughout codebase.
* NEWS: * doc/ref/api-control.texi: * doc/ref/api-data.texi: * doc/ref/api-debug.texi: * doc/ref/api-deprecated.texi: * doc/ref/api-evaluation.texi: * doc/ref/api-foreign.texi: * doc/ref/api-i18n.texi: * doc/ref/api-io.texi: * doc/ref/api-languages.texi: * doc/ref/api-macros.texi: * doc/ref/api-memory.texi: * doc/ref/api-modules.texi: * doc/ref/api-options.texi: * doc/ref/api-peg.texi: * doc/ref/api-procedures.texi: * doc/ref/api-scheduling.texi: * doc/ref/api-undocumented.texi: * doc/ref/api-utility.texi: * doc/ref/expect.texi: * doc/ref/goops.texi: * doc/ref/misc-modules.texi: * doc/ref/posix.texi: * doc/ref/repl-modules.texi: * doc/ref/scheme-ideas.texi: * doc/ref/scheme-scripts.texi: * doc/ref/srfi-modules.texi: * gc-benchmarks/larceny/dynamic.sch: * gc-benchmarks/larceny/twobit-input-long.sch: * gc-benchmarks/larceny/twobit.sch: * libguile/gc.h: * libguile/ioext.c: * libguile/list.c: * libguile/options.c: * libguile/posix.c: * libguile/threads.c: * module/ice-9/boot-9.scm: * module/ice-9/optargs.scm: * module/ice-9/ports.scm: * module/ice-9/pretty-print.scm: * module/ice-9/psyntax.scm: * module/language/elisp/parser.scm: * module/language/tree-il/compile-bytecode.scm: * module/srfi/srfi-37.scm: * module/srfi/srfi-43.scm: * module/statprof.scm: * module/texinfo/reflection.scm: * test-suite/tests/eval.test: * test-suite/tests/fluids.test: Fix typos. Signed-off-by: Ludovic Courtès <ludo@gnu.org>
This commit is contained in:
parent
5fcf6ff17a
commit
f27e8b855f
49 changed files with 409 additions and 400 deletions
2
NEWS
2
NEWS
|
@ -9549,7 +9549,7 @@ Use scm_object_to_string instead.
|
|||
|
||||
** Deprecated function: scm_wta
|
||||
|
||||
Use scm_wrong_type_arg, or another appropriate error signalling function
|
||||
Use scm_wrong_type_arg, or another appropriate error signaling function
|
||||
instead.
|
||||
|
||||
** Explicit support for obarrays has been deprecated.
|
||||
|
|
|
@ -404,7 +404,7 @@ For example,
|
|||
|
||||
Note that each @code{break} and @code{continue} procedure can only be
|
||||
used within the dynamic extent of its @code{while}. Outside the
|
||||
@code{while} their behaviour is unspecified.
|
||||
@code{while} their behavior is unspecified.
|
||||
@end deffn
|
||||
|
||||
@cindex named let
|
||||
|
@ -1553,7 +1553,7 @@ The above @code{scm_with_throw_handler} takes Scheme procedures as body
|
|||
(thunk) and handler arguments. @code{scm_c_with_throw_handler} is an
|
||||
equivalent taking C functions. See @code{scm_c_catch}
|
||||
(@pxref{Exceptions and C}) for a description of the parameters, the
|
||||
behaviour however of course follows @code{with-throw-handler}.
|
||||
behavior however of course follows @code{with-throw-handler}.
|
||||
@end deftypefn
|
||||
|
||||
|
||||
|
@ -1996,7 +1996,7 @@ dynamic state object.
|
|||
@deffnx {C Function} scm_set_current_dynamic_state (state)
|
||||
Restore the saved fluid-value associations from @var{state}, replacing
|
||||
the current fluid-value associations. Return the current fluid-value
|
||||
associatoins as a dynamic state object, as in
|
||||
associations as a dynamic state object, as in
|
||||
@code{current-dynamic-state}.
|
||||
@end deffn
|
||||
|
||||
|
@ -2302,7 +2302,7 @@ Output}), and the corresponding arguments in the @var{args} list.
|
|||
@end deftypefn
|
||||
|
||||
|
||||
@subsubsection Signalling Type Errors
|
||||
@subsubsection Signaling Type Errors
|
||||
|
||||
Every function visible at the Scheme level should aggressively check the
|
||||
types of its arguments, to avoid misinterpreting a value, and perhaps
|
||||
|
|
|
@ -767,7 +767,7 @@ otherwise.
|
|||
Return a @code{1} if the number @var{z} is exact, and @code{0}
|
||||
otherwise. This is equivalent to @code{scm_is_true (scm_exact_p (z))}.
|
||||
|
||||
An alternate approch to testing the exactness of a number is to
|
||||
An alternate approach to testing the exactness of a number is to
|
||||
use @code{scm_is_signed_integer} or @code{scm_is_unsigned_integer}.
|
||||
@end deftypefn
|
||||
|
||||
|
@ -3663,12 +3663,16 @@ case-insensitively.
|
|||
|
||||
@deffn {Scheme Procedure} string-hash s [bound [start [end]]]
|
||||
@deffnx {C Function} scm_substring_hash (s, bound, start, end)
|
||||
Compute a hash value for @var{s}. The optional argument @var{bound} is a non-negative exact integer specifying the range of the hash function. A positive value restricts the return value to the range [0,bound).
|
||||
Compute a hash value for @var{s}. The optional argument @var{bound} is
|
||||
a non-negative exact integer specifying the range of the hash function.
|
||||
A positive value restricts the return value to the range [0,bound).
|
||||
@end deffn
|
||||
|
||||
@deffn {Scheme Procedure} string-hash-ci s [bound [start [end]]]
|
||||
@deffnx {C Function} scm_substring_hash_ci (s, bound, start, end)
|
||||
Compute a hash value for @var{s}. The optional argument @var{bound} is a non-negative exact integer specifying the range of the hash function. A positive value restricts the return value to the range [0,bound).
|
||||
Compute a hash value for @var{s}. The optional argument @var{bound} is
|
||||
a non-negative exact integer specifying the range of the hash function.
|
||||
A positive value restricts the return value to the range [0,bound).
|
||||
@end deffn
|
||||
|
||||
Because the same visual appearance of an abstract Unicode character can
|
||||
|
@ -4229,7 +4233,8 @@ a predicate, if it is a character, it is tested for equality and if it
|
|||
is a character set, it is tested for membership.
|
||||
@end deffn
|
||||
|
||||
The following additional functions are available in the module @code{(ice-9 string-fun)}. They can be used with:
|
||||
The following additional functions are available in the module
|
||||
@code{(ice-9 string-fun)}. They can be used with:
|
||||
|
||||
@example
|
||||
(use-modules (ice-9 string-fun))
|
||||
|
@ -4248,7 +4253,7 @@ Return a new string where every instance of @var{substring} in string
|
|||
@node Representing Strings as Bytes
|
||||
@subsubsection Representing Strings as Bytes
|
||||
|
||||
Out in the cold world outside of Guile, not all strings are treated in
|
||||
In the cold world outside of Guile, not all strings are treated in
|
||||
the same way. Out there there are only bytes, and there are many ways
|
||||
of representing a strings (sequences of characters) as binary data
|
||||
(sequences of bytes).
|
||||
|
@ -4670,15 +4675,15 @@ themselves to @code{eq?} comparison. But symbols are more descriptive
|
|||
than numbers, because a symbol's name can be used directly to describe
|
||||
the concept for which that symbol stands.
|
||||
|
||||
For example, imagine that you need to represent some colours in a
|
||||
For example, imagine that you need to represent some colors in a
|
||||
computer program. Using numbers, you would have to choose arbitrarily
|
||||
some mapping between numbers and colours, and then take care to use that
|
||||
some mapping between numbers and colors, and then take care to use that
|
||||
mapping consistently:
|
||||
|
||||
@lisp
|
||||
;; 1=red, 2=green, 3=purple
|
||||
|
||||
(if (eq? (colour-of vehicle) 1)
|
||||
(if (eq? (color-of vehicle) 1)
|
||||
...)
|
||||
@end lisp
|
||||
|
||||
|
@ -4691,16 +4696,16 @@ defining constants:
|
|||
(define green 2)
|
||||
(define purple 3)
|
||||
|
||||
(if (eq? (colour-of vehicle) red)
|
||||
(if (eq? (color-of vehicle) red)
|
||||
...)
|
||||
@end lisp
|
||||
|
||||
@noindent
|
||||
But the simplest and clearest approach is not to use numbers at all, but
|
||||
symbols whose names specify the colours that they refer to:
|
||||
symbols whose names specify the colors that they refer to:
|
||||
|
||||
@lisp
|
||||
(if (eq? (colour-of vehicle) 'red)
|
||||
(if (eq? (color-of vehicle) 'red)
|
||||
...)
|
||||
@end lisp
|
||||
|
||||
|
@ -4754,7 +4759,7 @@ mixing all the properties up together in a flat list, we could use an
|
|||
association list like this:
|
||||
|
||||
@lisp
|
||||
(define car1-properties '((colour . red)
|
||||
(define car1-properties '((color . red)
|
||||
(transmission . manual)
|
||||
(fuel . unleaded)
|
||||
(steering . power-assisted)))
|
||||
|
@ -4767,11 +4772,11 @@ It also allows further properties to use the same symbols among their
|
|||
possible values without becoming ambiguous:
|
||||
|
||||
@lisp
|
||||
(define car1-properties '((colour . red)
|
||||
(define car1-properties '((color . red)
|
||||
(transmission . manual)
|
||||
(fuel . unleaded)
|
||||
(steering . power-assisted)
|
||||
(seat-colour . red)
|
||||
(seat-color . red)
|
||||
(locking . manual)))
|
||||
@end lisp
|
||||
|
||||
|
@ -4783,13 +4788,13 @@ extract or change individual pieces of information:
|
|||
(assq-ref car1-properties 'fuel) @result{} unleaded
|
||||
(assq-ref car1-properties 'transmission) @result{} manual
|
||||
|
||||
(assq-set! car1-properties 'seat-colour 'black)
|
||||
(assq-set! car1-properties 'seat-color 'black)
|
||||
@result{}
|
||||
((colour . red)
|
||||
((color . red)
|
||||
(transmission . manual)
|
||||
(fuel . unleaded)
|
||||
(steering . power-assisted)
|
||||
(seat-colour . black)
|
||||
(seat-color . black)
|
||||
(locking . manual)))
|
||||
@end lisp
|
||||
|
||||
|
@ -4927,11 +4932,11 @@ reading symbols case-insensitively, @var{str} is converted to lowercase
|
|||
before the returned symbol is looked up or created.
|
||||
@end deffn
|
||||
|
||||
The following examples illustrate Guile's detailed behaviour as regards
|
||||
The following examples illustrate Guile's detailed behavior as regards
|
||||
the case-sensitivity of symbols:
|
||||
|
||||
@lisp
|
||||
(read-enable 'case-insensitive) ; R5RS compliant behaviour
|
||||
(read-enable 'case-insensitive) ; R5RS compliant behavior
|
||||
|
||||
(symbol->string 'flying-fish) @result{} "flying-fish"
|
||||
(symbol->string 'Martin) @result{} "martin"
|
||||
|
@ -4947,7 +4952,7 @@ the case-sensitivity of symbols:
|
|||
(symbol->string
|
||||
(string->symbol "K. Harper, M.D."))) @result{} #t
|
||||
|
||||
(read-disable 'case-insensitive) ; Guile default behaviour
|
||||
(read-disable 'case-insensitive) ; Guile default behavior
|
||||
|
||||
(symbol->string 'flying-fish) @result{} "flying-fish"
|
||||
(symbol->string 'Martin) @result{} "Martin"
|
||||
|
@ -5752,7 +5757,7 @@ up a list. An example will clear that up:
|
|||
|
||||
This example also shows that lists have to be quoted when written
|
||||
(@pxref{Expression Syntax}), because they would otherwise be
|
||||
mistakingly taken as procedure applications (@pxref{Simple
|
||||
mistakenly taken as procedure applications (@pxref{Simple
|
||||
Invocation}).
|
||||
|
||||
|
||||
|
@ -5863,7 +5868,7 @@ Return the number of elements in list @var{lst}.
|
|||
|
||||
@deffn {Scheme Procedure} last-pair lst
|
||||
@deffnx {C Function} scm_last_pair (lst)
|
||||
Return the last pair in @var{lst}, signalling an error if
|
||||
Return the last pair in @var{lst}, signaling an error if
|
||||
@var{lst} is circular.
|
||||
@end deffn
|
||||
|
||||
|
@ -9382,7 +9387,7 @@ procedures for manipulating them.
|
|||
@subsubsection Alist Key Equality
|
||||
|
||||
All of Guile's dedicated association list procedures, apart from
|
||||
@code{acons}, come in three flavours, depending on the level of equality
|
||||
@code{acons}, come in three flavors, depending on the level of equality
|
||||
that is required to decide whether an existing key in the association
|
||||
list is the same as the key that the procedure call uses to identify the
|
||||
required entry.
|
||||
|
|
|
@ -59,7 +59,7 @@ x @result{} 123
|
|||
@end example
|
||||
|
||||
@item (@var{proc} @var{args}@dots{})
|
||||
A parenthesised expression is a function call. @var{proc} and each
|
||||
A parenthesized expression is a function call. @var{proc} and each
|
||||
argument are evaluated, then the function (which @var{proc} evaluated
|
||||
to) is called with those arguments.
|
||||
|
||||
|
@ -73,7 +73,7 @@ unspecified, so be careful when using expressions with side effects.
|
|||
((get-some-proc) 1 2 3) @result{} 1
|
||||
@end example
|
||||
|
||||
The same sort of parenthesised form is used for a macro invocation,
|
||||
The same sort of parenthesized form is used for a macro invocation,
|
||||
but in that case the arguments are not evaluated. See the
|
||||
descriptions of macros for more on this (@pxref{Macros}, and
|
||||
@pxref{Syntax Rules}).
|
||||
|
@ -318,7 +318,7 @@ the current input port if @var{port} is not specified.
|
|||
Any whitespace before the next token is discarded.
|
||||
@end deffn
|
||||
|
||||
The behaviour of Guile's Scheme reader can be modified by manipulating
|
||||
The behavior of Guile's Scheme reader can be modified by manipulating
|
||||
its read options.
|
||||
|
||||
@cindex options - read
|
||||
|
@ -392,7 +392,7 @@ For more information on the @code{r7rs-symbols} option, see
|
|||
|
||||
When something goes wrong with a Scheme program, the user will want to
|
||||
know how to fix it. This starts with identifying where the error
|
||||
occured: we want to associate a source location with each component part
|
||||
occurred: we want to associate a source location with each component part
|
||||
of source code, and propagate that source location information through
|
||||
to the compiler or interpreter.
|
||||
|
||||
|
@ -1339,14 +1339,14 @@ and space used by a piece of code.
|
|||
|
||||
@deffn {Scheme Procedure} call-with-time-limit limit thunk limit-reached
|
||||
Call @var{thunk}, but cancel it if @var{limit} seconds of wall-clock
|
||||
time have elapsed. If the computation is cancelled, call
|
||||
time have elapsed. If the computation is canceled, call
|
||||
@var{limit-reached} in tail position. @var{thunk} must not disable
|
||||
interrupts or prevent an abort via a @code{dynamic-wind} unwind handler.
|
||||
@end deffn
|
||||
|
||||
@deffn {Scheme Procedure} call-with-allocation-limit limit thunk limit-reached
|
||||
Call @var{thunk}, but cancel it if @var{limit} bytes have been
|
||||
allocated. If the computation is cancelled, call @var{limit-reached} in
|
||||
allocated. If the computation is canceled, call @var{limit-reached} in
|
||||
tail position. @var{thunk} must not disable interrupts or prevent an
|
||||
abort via a @code{dynamic-wind} unwind handler.
|
||||
|
||||
|
@ -1407,7 +1407,7 @@ defaults to @code{all-pure-bindings}. This is the core of the
|
|||
sandbox: creating a scope for the expression that is @dfn{safe}.
|
||||
|
||||
A safe sandbox module has two characteristics. Firstly, it will not
|
||||
allow the expression being evaluated to avoid being cancelled due to
|
||||
allow the expression being evaluated to avoid being canceled due to
|
||||
time or allocation limits. This ensures that the expression terminates
|
||||
in a timely fashion.
|
||||
|
||||
|
@ -1628,7 +1628,7 @@ with no arguments.
|
|||
Closes the connection on all running server sockets.
|
||||
|
||||
Please note that in the current implementation, the REPL threads are
|
||||
cancelled without unwinding their stacks. If any of them are holding
|
||||
canceled without unwinding their stacks. If any of them are holding
|
||||
mutexes or are within a critical section, the results are unspecified.
|
||||
@end deffn
|
||||
|
||||
|
|
|
@ -108,7 +108,7 @@ Unless @var{library} denotes an absolute file name or otherwise contains
|
|||
a directory separator (@code{/}, and also @code{\} on Windows), Guile
|
||||
will search for the library in the directories listed in
|
||||
@var{search-paths}. The default search path has three components, which
|
||||
can all be overriden by colon-delimited (semicolon on Windows)
|
||||
can all be overridden by colon-delimited (semicolon on Windows)
|
||||
environment variables:
|
||||
|
||||
@table @env
|
||||
|
@ -146,7 +146,7 @@ We don't use libltdl now, essentially for flexibility and
|
|||
error-reporting reasons. But, to keep this old use-case working, if
|
||||
@var{search-ltdl-library-path?} is true, we add each entry of
|
||||
@code{LTDL_LIBRARY_PATH} to the default extensions load path,
|
||||
additionally adding the @file{.libs} subdirextories for each entry, in
|
||||
additionally adding the @file{.libs} subdirectories for each entry, in
|
||||
case there are @file{.so} files there instead of alongside the
|
||||
@file{.la} files.
|
||||
@item GUILE_SYSTEM_EXTENSIONS_PATH
|
||||
|
@ -305,7 +305,7 @@ Note that the new primitives that the extension adds to Guile with
|
|||
@code{scm_c_define_gsubr} (@pxref{Primitive Procedures}) or with any of
|
||||
the other mechanisms are placed into the module that is current when the
|
||||
@code{scm_c_define_gsubr} is executed, so to be clear about what goes
|
||||
vwhere it's best to include the @code{load-extension} in a module, as
|
||||
where it's best to include the @code{load-extension} in a module, as
|
||||
above. Alternately, the C code can use @code{scm_c_define_module} to
|
||||
specify which module is being created:
|
||||
|
||||
|
@ -326,7 +326,7 @@ init_math_bessel ()
|
|||
|
||||
And yet... if what we want is just the @code{j0} function, it seems like
|
||||
a lot of ceremony to have to compile a Guile-specific wrapper library
|
||||
complete with an initialization function and wraper module to allow
|
||||
complete with an initialization function and wrapper module to allow
|
||||
Guile users to call it. There is another way, but to get there, we have
|
||||
to talk about function pointers and function types first. @xref{Foreign
|
||||
Functions}, to skip to the good parts.
|
||||
|
@ -427,7 +427,7 @@ will try to use ``pointer object'' to refer to Scheme objects, and
|
|||
Create a pointer object from a pointer value.
|
||||
|
||||
If @var{finalizer} is non-null, Guile arranges to call it on the pointer
|
||||
value at some point after the pointer object becomes collectable.
|
||||
value at some point after the pointer object becomes collectible.
|
||||
@end deftypefn
|
||||
|
||||
@deftypefn {C Function} void* scm_to_pointer (SCM obj)
|
||||
|
@ -469,7 +469,7 @@ C types.
|
|||
@defvrx {Scheme Variable} complex-float
|
||||
These values represent the C numeric types of the specified sizes and
|
||||
signednesses. @code{complex-float} and @code{complex-double} stand for
|
||||
C99 @code{float _Complex} and @code{double _Complex} respecively.
|
||||
C99 @code{float _Complex} and @code{double _Complex} respectively.
|
||||
@end defvr
|
||||
|
||||
In addition there are some convenience bindings for indicating types of
|
||||
|
@ -533,7 +533,7 @@ return two values, with @code{errno} as the second value.
|
|||
@end deffn
|
||||
|
||||
Finally, in @code{(system foreign-library)} there is a convenient
|
||||
wrapper function, joining together @code{foreign-libary-pointer} and
|
||||
wrapper function, joining together @code{foreign-library-pointer} and
|
||||
@code{procedure->pointer}:
|
||||
|
||||
@deffn {Scheme Procedure} foreign-library-function lib name @
|
||||
|
|
|
@ -482,7 +482,7 @@ message strings (@pxref{Introduction,,, gettext, GNU @code{gettext}
|
|||
utilities}).
|
||||
|
||||
Messages are collected in domains, so different libraries and programs
|
||||
maintain different message catalogues. The @var{domain} parameter in
|
||||
maintain different message catalogs. The @var{domain} parameter in
|
||||
the functions below is a string (it becomes part of the message
|
||||
catalog filename).
|
||||
|
||||
|
@ -500,7 +500,7 @@ below. @var{category} is optional and defaults to @code{LC_MESSAGES}
|
|||
|
||||
Normal usage is for @var{msg} to be a literal string.
|
||||
@command{xgettext} can extract those from the source to form a message
|
||||
catalogue ready for translators (@pxref{xgettext Invocation,, Invoking
|
||||
catalog ready for translators (@pxref{xgettext Invocation,, Invoking
|
||||
the @command{xgettext} Program, gettext, GNU @code{gettext}
|
||||
utilities}).
|
||||
|
||||
|
@ -539,12 +539,12 @@ with a plural form chosen appropriately for the number @var{n}.
|
|||
|
||||
@var{msg} is the singular form, and @var{msgplural} the plural. When
|
||||
no translation is available, @var{msg} is used if @math{@var{n} = 1},
|
||||
or @var{msgplural} otherwise. When translated, the message catalogue
|
||||
or @var{msgplural} otherwise. When translated, the message catalog
|
||||
can have a different rule, and can have more than two possible forms.
|
||||
|
||||
As per @code{gettext} above, normal usage is for @var{msg} and
|
||||
@var{msgplural} to be literal strings, since @command{xgettext} can
|
||||
extract them from the source to build a message catalogue. For
|
||||
extract them from the source to build a message catalog. For
|
||||
example,
|
||||
|
||||
@example
|
||||
|
@ -593,7 +593,7 @@ For example,
|
|||
When using Autoconf/Automake, an application should arrange for the
|
||||
configured @code{localedir} to get into the program (by substituting,
|
||||
or by generating a config file) and set that for its domain. This
|
||||
ensures the catalogue can be found even when installed in a
|
||||
ensures the catalog can be found even when installed in a
|
||||
non-standard location.
|
||||
@end deffn
|
||||
|
||||
|
@ -622,7 +622,7 @@ without any recoding. For that reason source message strings are best
|
|||
as plain ASCII.
|
||||
|
||||
Currently Guile has no understanding of multi-byte characters, and
|
||||
string functions won't recognise character boundaries in multi-byte
|
||||
string functions won't recognize character boundaries in multi-byte
|
||||
strings. An application will at least be able to pass such strings
|
||||
through to some output though. Perhaps this will change in the
|
||||
future.
|
||||
|
|
|
@ -18,7 +18,7 @@
|
|||
* Line/Delimited:: Read and write lines or delimited text.
|
||||
* Default Ports:: Defaults for input, output and errors.
|
||||
* Port Types:: Types of port and how to make them.
|
||||
* Venerable Port Interfaces:: Procedures from the last millenium.
|
||||
* Venerable Port Interfaces:: Procedures from the last millennium.
|
||||
* Using Ports from C:: Nice interfaces for C.
|
||||
* Non-Blocking I/O:: How Guile deals with EWOULDBLOCK.
|
||||
* BOM Handling:: Handling of Unicode byte order marks.
|
||||
|
@ -89,6 +89,7 @@ on interfaces to control port buffering.
|
|||
@deffn {Scheme Procedure} port? x
|
||||
@deffnx {C Function} scm_port_p (x)
|
||||
Return a boolean indicating whether @var{x} is a port.
|
||||
Equivalent to @code{(or (input-port? @var{x}) (output-port? @var{x}))}.
|
||||
@end deffn
|
||||
|
||||
@rnindex input-port?
|
||||
|
@ -633,7 +634,7 @@ Return the current column number or line number of @var{port}.
|
|||
@end deffn
|
||||
|
||||
Port lines and positions are represented as 0-origin integers, which is
|
||||
to say that the the first character of the first line is line 0, column
|
||||
to say that the first character of the first line is line 0, column
|
||||
0. However, when you display a line number, for example in an error
|
||||
message, we recommend you add 1 to get 1-origin integers. This is
|
||||
because lines numbers traditionally start with 1, and that is what
|
||||
|
@ -754,7 +755,7 @@ line-buffered ports, respectively. @xref{File Ports}, for more.
|
|||
|
||||
Any buffered output data will be written out when the port is closed.
|
||||
To make sure to flush it at specific points in your program, use
|
||||
@code{force-otput}.
|
||||
@code{force-output}.
|
||||
|
||||
@findex fflush
|
||||
@deffn {Scheme Procedure} force-output [port]
|
||||
|
@ -996,15 +997,15 @@ Return the current input port. This is the default port used
|
|||
by many input procedures.
|
||||
|
||||
Initially this is the @dfn{standard input} in Unix and C terminology.
|
||||
When the standard input is a tty the port is unbuffered, otherwise
|
||||
When the standard input is a TTY the port is unbuffered, otherwise
|
||||
it's fully buffered.
|
||||
|
||||
Unbuffered input is good if an application runs an interactive
|
||||
subprocess, since any type-ahead input won't go into Guile's buffer
|
||||
and be unavailable to the subprocess.
|
||||
|
||||
Note that Guile buffering is completely separate from the tty ``line
|
||||
discipline''. In the usual cooked mode on a tty Guile only sees a
|
||||
Note that Guile buffering is completely separate from the TTY ``line
|
||||
discipline''. In the usual cooked mode on a TTY Guile only sees a
|
||||
line of input once the user presses @key{Return}.
|
||||
@end deffn
|
||||
|
||||
|
@ -1016,10 +1017,10 @@ Return the current output port. This is the default port used
|
|||
by many output procedures.
|
||||
|
||||
Initially this is the @dfn{standard output} in Unix and C terminology.
|
||||
When the standard output is a tty this port is unbuffered, otherwise
|
||||
When the standard output is a TTY this port is unbuffered, otherwise
|
||||
it's fully buffered.
|
||||
|
||||
Unbuffered output to a tty is good for ensuring progress output or a
|
||||
Unbuffered output to a TTY is good for ensuring progress output or a
|
||||
prompt is seen. But an application which always prints whole lines
|
||||
could change to line buffered, or an application with a lot of output
|
||||
could go fully buffered and perhaps make explicit @code{force-output}
|
||||
|
@ -1032,7 +1033,7 @@ calls (@pxref{Buffering}) at selected points.
|
|||
Return the port to which errors and warnings should be sent.
|
||||
|
||||
Initially this is the @dfn{standard error} in Unix and C terminology.
|
||||
When the standard error is a tty this port is unbuffered, otherwise
|
||||
When the standard error is a TTY this port is unbuffered, otherwise
|
||||
it's fully buffered.
|
||||
@end deffn
|
||||
|
||||
|
@ -1095,7 +1096,7 @@ See also @ref{Ports and File Descriptors, open}, for an interface
|
|||
to the Unix @code{open} system call.
|
||||
|
||||
All file access uses the ``LFS'' large file support functions when
|
||||
available, so files bigger than 2 Gbytes (@math{2^31} bytes) can be
|
||||
available, so files bigger than 2 gibibytes (@math{2^31} bytes) can be
|
||||
read and written on a 32-bit system.
|
||||
|
||||
Most systems have limits on how many files can be open, so it's
|
||||
|
@ -1735,7 +1736,7 @@ in-depth discussion.
|
|||
These methods must be implemented if the @code{#:read} or @code{#:write}
|
||||
method can return @code{#f}, and should return a non-negative integer
|
||||
file descriptor. However they may be called explicitly by a user, for
|
||||
example to determine if a port may eventually be readable or writeable.
|
||||
example to determine if a port may eventually be readable or writable.
|
||||
If there is no associated file descriptor with the port, they should
|
||||
return @code{#f}. The default implementation returns @code{#f}.
|
||||
@end deffn
|
||||
|
@ -1937,7 +1938,7 @@ together. We document that set of primitives, design our internal
|
|||
interfaces around them, and recommend them to users. As the R6RS I/O
|
||||
system is the most capable standard that Scheme has yet produced in this
|
||||
domain, we mostly recommend that; @code{(ice-9 binary-ports)} and
|
||||
@code{(ice-9 textual-ports)} are wholly modelled on @code{(rnrs io
|
||||
@code{(ice-9 textual-ports)} are wholly modeled on @code{(rnrs io
|
||||
ports)}. Guile does not wholly copy R6RS, however; @xref{R6RS
|
||||
Incompatibilities}.
|
||||
|
||||
|
|
|
@ -279,7 +279,7 @@ documentation are most welcome!
|
|||
was not the first non-Schemey language implemented by Guile, but it was
|
||||
the first implemented for Guile's bytecode compiler. The goal was to
|
||||
support ECMAScript version 3.1, a relatively small language, but the
|
||||
implementor was completely irresponsible and got distracted by other
|
||||
implementer was completely irresponsible and got distracted by other
|
||||
things before finishing the standard library, and even some bits of the
|
||||
syntax. So, ECMAScript does deserve a mention in the manual, but it
|
||||
doesn't deserve an endorsement until its implementation is completed,
|
||||
|
|
|
@ -161,7 +161,8 @@ patterns are made of lists, improper lists, vectors, identifiers, and datums.
|
|||
Users can match a sequence of patterns using the ellipsis (@code{...}).
|
||||
|
||||
Identifiers in a pattern are called @dfn{literals} if they are present in the
|
||||
@code{syntax-rules} literals list, and @dfn{pattern variables} otherwise. When
|
||||
@code{syntax-rules} literals list, and @dfn{pattern variables}
|
||||
otherwise. When
|
||||
building up the macro output, the expander replaces instances of a pattern
|
||||
variable in the template with the matched subexpression.
|
||||
|
||||
|
@ -261,7 +262,7 @@ auxiliary syntax definitions, as specified by R6RS and R7RS:
|
|||
@deffnx {Scheme Syntax} ...
|
||||
Auxiliary syntax definitions.
|
||||
|
||||
These are defined as if with a macro that never matches, e.g.:
|
||||
These are defined with a macro that never matches, e.g.:
|
||||
|
||||
@example
|
||||
(define-syntax else (syntax-rules ()))
|
||||
|
@ -463,8 +464,9 @@ Primer for the Merely Eccentric}.@footnote{Archived from
|
|||
worthy of Scheme.
|
||||
|
||||
@deffn {Syntax} syntax-case syntax literals (pattern [guard] exp) @dots{}
|
||||
Match the syntax object @var{syntax} against the given patterns, in order. If a
|
||||
@var{pattern} matches, return the result of evaluating the associated @var{exp}.
|
||||
Match the syntax object @var{syntax} against the given patterns, in
|
||||
order. If a @var{pattern} matches, return the result of evaluating the
|
||||
associated @var{exp}.
|
||||
@end deffn
|
||||
|
||||
Compare the following definitions of @code{when}:
|
||||
|
@ -523,8 +525,9 @@ syntax objects as is needed to maintain referential transparency.
|
|||
Create a syntax object wrapping @var{form} within the current lexical context.
|
||||
@end deffn
|
||||
|
||||
Syntax objects are typically created internally to the process of expansion, but
|
||||
it is possible to create them outside of syntax expansion:
|
||||
Syntax objects are typically created internally to facilitate the
|
||||
process of expansion, but it is possible to create them outside of
|
||||
syntax expansion:
|
||||
|
||||
@example
|
||||
(syntax (foo bar baz))
|
||||
|
@ -588,9 +591,9 @@ verbose, which is true. But there is a difference: @code{syntax-case} creates
|
|||
@emph{procedural} macros, giving the full power of Scheme to the macro expander.
|
||||
This has many practical applications.
|
||||
|
||||
A common desire is to be able to match a form only if it is an identifier. This
|
||||
is impossible with @code{syntax-rules}, given the datum matching forms. But with
|
||||
@code{syntax-case} it is easy:
|
||||
A common desire is to be able to match a form only if it is an
|
||||
identifier. This is impossible with @code{syntax-rules}, given the
|
||||
datum matching forms. But with @code{syntax-case} it is easy:
|
||||
|
||||
@deffn {Scheme Procedure} identifier? syntax-object
|
||||
Returns @code{#t} if @var{syntax-object} is an identifier, or @code{#f}
|
||||
|
@ -877,7 +880,7 @@ objects.
|
|||
@end deffn
|
||||
|
||||
@deffn {Scheme Procedure} syntax-local-binding id [#:resolve-syntax-parameters?=#t]
|
||||
Resolve the identifer @var{id}, a syntax object, within the current
|
||||
Resolve the identifier @var{id}, a syntax object, within the current
|
||||
lexical environment, and return two values, the binding type and a
|
||||
binding value. The binding type is a symbol, which may be one of the
|
||||
following:
|
||||
|
@ -1240,7 +1243,7 @@ evaluated at expansion time, in the order that they appear in the compilation
|
|||
unit (file).
|
||||
|
||||
But if a syntactic definition needs to call out to a normal procedure at
|
||||
expansion-time, it might well need need special declarations to indicate that
|
||||
expansion-time, it might well need special declarations to indicate that
|
||||
the procedure should be made available at expansion-time.
|
||||
|
||||
For example, the following code tries to embed a compilation
|
||||
|
@ -1252,7 +1255,7 @@ not in a file, as it cannot be byte-compiled:
|
|||
(use-modules (srfi srfi-19))
|
||||
(define start-date (date->string (current-date)))
|
||||
(define-syntax *compilation-date*
|
||||
(lambda (sintax)
|
||||
(lambda (syntax)
|
||||
start-date))
|
||||
(display *compilation-date*)
|
||||
(newline)
|
||||
|
@ -1269,7 +1272,7 @@ The fix is to use @code{eval-when}.
|
|||
(eval-when (expand load eval)
|
||||
(define start-date (date->string (current-date))))
|
||||
(define-syntax *compilation-date*
|
||||
(lambda (sintax)
|
||||
(lambda (syntax)
|
||||
start-date))
|
||||
(display *compilation-date*)
|
||||
(newline)
|
||||
|
@ -1369,7 +1372,7 @@ macro definition to be present at compile time as well, so you pass
|
|||
Compiler}.
|
||||
|
||||
It's a terrible interface; we know. The macroexpander is somewhat
|
||||
tricksy regarding modes, so unless you are building a macro-expanding
|
||||
tricky regarding modes, so unless you are building a macro-expanding
|
||||
tool, we suggest to avoid invoking it directly.
|
||||
|
||||
|
||||
|
|
|
@ -419,7 +419,7 @@ keys, or a value in a hash table with weak values does not prevent an
|
|||
object from being returned by a guardian. But as long as an object
|
||||
can be returned from a guardian it will not be removed from such a
|
||||
weak vector or hash table. In other words, a weak link does not
|
||||
prevent an object from being considered collectable, but being inside
|
||||
prevent an object from being considered collectible, but being inside
|
||||
a guardian prevents a weak link from being broken.
|
||||
|
||||
A key in a weak key hash table can be thought of as having a strong
|
||||
|
|
|
@ -360,7 +360,7 @@ in the sense of @code{#:replace}.
|
|||
@item #:version @var{list}
|
||||
@cindex module version
|
||||
Specify a version for the module in the form of @var{list}, a list of
|
||||
zero or more exact, nonnegative integers. The corresponding
|
||||
zero or more exact, non-negative integers. The corresponding
|
||||
@code{#:version} option in the @code{use-modules} form allows callers
|
||||
to restrict the value of this option in various ways.
|
||||
|
||||
|
@ -510,7 +510,7 @@ a declared version specifier of the same form as the one described in
|
|||
R6RS (@pxref{Library form, R6RS Library Form,, r6rs, The Revised^6
|
||||
Report on the Algorithmic Language Scheme}). By using the
|
||||
@code{#:version} keyword in a @code{define-module} form, a module may
|
||||
specify a version as a list of zero or more exact, nonnegative integers.
|
||||
specify a version as a list of zero or more exact, non-negative integers.
|
||||
|
||||
This version can then be used to locate the module during the module
|
||||
search process. Client modules and callers of the @code{use-modules}
|
||||
|
@ -536,7 +536,7 @@ in which @var{sub-version-reference} is in turn one of:
|
|||
(not @var{sub-version-reference})
|
||||
@end lisp
|
||||
|
||||
in which @var{sub-version} is an exact, nonnegative integer as above. A
|
||||
in which @var{sub-version} is an exact, non-negative integer as above. A
|
||||
version reference matches a declared module version if each element of
|
||||
the version reference matches a corresponding element of the module
|
||||
version, according to the following rules:
|
||||
|
|
|
@ -18,12 +18,12 @@ installation directories, configuration flags that control pieces of
|
|||
functionality being included or left out, etc.
|
||||
|
||||
@item
|
||||
differences in dynamically loaded code --- behaviour and features
|
||||
differences in dynamically loaded code --- behavior and features
|
||||
provided by modules that can be dynamically loaded into a running Guile
|
||||
|
||||
@item
|
||||
different runtime options --- some of the options that are provided for
|
||||
controlling Guile's behaviour may be set differently.
|
||||
controlling Guile's behavior may be set differently.
|
||||
@end itemize
|
||||
|
||||
Guile provides ``introspective'' variables and procedures to query all
|
||||
|
@ -34,7 +34,7 @@ documentation on what the options mean.
|
|||
@menu
|
||||
* Build Config:: Build and installation configuration.
|
||||
* Feature Tracking:: Available features in the Guile process.
|
||||
* Runtime Options:: Controlling Guile's runtime behaviour.
|
||||
* Runtime Options:: Controlling Guile's runtime behavior.
|
||||
@end menu
|
||||
|
||||
|
||||
|
@ -349,7 +349,7 @@ and friends (@pxref{Records}).
|
|||
|
||||
Although these tables may seem exhaustive, it is probably unwise in
|
||||
practice to rely on them, as the correspondences between feature symbols
|
||||
and available procedures/behaviour are not strictly defined. If you are
|
||||
and available procedures/behavior are not strictly defined. If you are
|
||||
writing code that needs to check for the existence of some procedure, it
|
||||
is probably safer to do so directly using the @code{defined?} procedure
|
||||
than to test for the corresponding feature using @code{provided?}.
|
||||
|
@ -358,7 +358,7 @@ than to test for the corresponding feature using @code{provided?}.
|
|||
@node Runtime Options
|
||||
@subsection Runtime Options
|
||||
|
||||
There are a number of runtime options available for paramaterizing
|
||||
There are a number of runtime options available for parameterizing
|
||||
built-in procedures, like @code{read}, and built-in behavior, like what
|
||||
happens on an uncaught error.
|
||||
|
||||
|
|
|
@ -716,7 +716,7 @@ This produces rather pretty parse trees:
|
|||
|
||||
Notice that when there's no entry in a field (e.g. @code{nameORcomment}
|
||||
for messagebus) the symbol is inserted. This is the ``don't throw away
|
||||
any information'' rule---we succesfully matched a @code{nameORcomment}
|
||||
any information'' rule---we successfully matched a @code{nameORcomment}
|
||||
of 0 characters (since we used @code{*} when defining it). This is
|
||||
usually what you want, because it allows you to e.g. use @code{list-ref}
|
||||
to pull out elements (since they all have known offsets).
|
||||
|
|
|
@ -181,7 +181,7 @@ other threads, which might not be what you want. Or, it might escape
|
|||
via explicit reification via @code{current-dynamic-state}.
|
||||
|
||||
Of course, this dynamic scoping might be exactly what you want; that's
|
||||
why fluids and parameters work this way, and is what you want for for
|
||||
why fluids and parameters work this way, and is what you want for
|
||||
many common parameters such as the current input and output ports, the
|
||||
current locale conversion parameters, and the like. Perhaps this is the
|
||||
case for most parameters, even. If your use case for thread-local
|
||||
|
@ -205,7 +205,7 @@ not inherit thread-local fluid values from the parent thread.
|
|||
|
||||
@deffn {Scheme Procedure} fluid-thread-local? fluid
|
||||
@deffnx {C Function} scm_fluid_thread_local_p (fluid)
|
||||
Return @code{#t} if the fluid @var{fluid} is is thread-local, or
|
||||
Return @code{#t} if the fluid @var{fluid} is thread-local, or
|
||||
@code{#f} otherwise.
|
||||
@end deffn
|
||||
|
||||
|
@ -258,11 +258,11 @@ C signal handlers.)
|
|||
|
||||
Though an interrupt procedure can have any side effect permitted to
|
||||
Guile code, asynchronous interrupts are generally used either for
|
||||
profiling or for prematurely cancelling a computation. The former case
|
||||
profiling or for prematurely canceling a computation. The former case
|
||||
is mostly transparent to the program being run, by design, but the
|
||||
latter case can introduce bugs. Like finalizers (@pxref{Foreign Object
|
||||
Memory Management}), asynchronous interrupts introduce concurrency in a
|
||||
program. An asyncronous interrupt can run in the middle of some
|
||||
program. An asynchronous interrupt can run in the middle of some
|
||||
mutex-protected operation, for example, and potentially corrupt the
|
||||
program's state.
|
||||
|
||||
|
@ -338,7 +338,7 @@ and that it should avoid waiting.
|
|||
@deftypefn {C Function} int scm_c_prepare_to_wait_on_cond (scm_i_pthread_mutex_t *mutex, scm_i_pthread_cond_t *cond)
|
||||
Inform Guile that the current thread is about to sleep, and that if an
|
||||
asynchronous interrupt is signaled on this thread, Guile should wake up
|
||||
the thread by acquiring @var{mutex} and signalling @var{cond}. The
|
||||
the thread by acquiring @var{mutex} and signaling @var{cond}. The
|
||||
caller must already hold @var{mutex} and only drop it as part of the
|
||||
@code{pthread_cond_wait} call. Returns zero if the prepare succeeded,
|
||||
or nonzero if the thread already has a pending async and that it should
|
||||
|
@ -492,7 +492,7 @@ re-entry, and you might not have to worry about early exit either.
|
|||
|
||||
However, do consider the possibility of asynchronous interrupts
|
||||
(@pxref{Asyncs}). If the user interrupts your code interactively, that
|
||||
can cause an exception; or your thread might be cancelled, which does
|
||||
can cause an exception; or your thread might be canceled, which does
|
||||
the same; or the user could be running your code under some pre-emptive
|
||||
system that periodically causes lightweight task switching. (Guile does
|
||||
not currently include such a system, but it's possible to implement as a
|
||||
|
@ -526,7 +526,7 @@ Finally, calling @code{make-mutex} with the symbol
|
|||
@code{allow-external-unlock} creates an unowned mutex. An unowned mutex
|
||||
is like a standard mutex, except that it can be unlocked by any thread.
|
||||
A corollary of this behavior is that a thread's attempt to lock a mutex
|
||||
that it already owns will block instead of signalling an error, as it
|
||||
that it already owns will block instead of signaling an error, as it
|
||||
could be that some other thread unlocks the mutex, allowing the owner
|
||||
thread to proceed. This kind of mutex is a bit strange and is here for
|
||||
use by SRFI-18.
|
||||
|
|
|
@ -501,7 +501,7 @@ Once the procedures have been added, we can invoke the hook using
|
|||
@end lisp
|
||||
|
||||
Note that the procedures are called in the reverse of the order with
|
||||
which they were added. This is because the default behaviour of
|
||||
which they were added. This is because the default behavior of
|
||||
@code{add-hook!} is to add its procedure to the @emph{front} of the
|
||||
hook's procedure list. You can force @code{add-hook!} to add its
|
||||
procedure to the @emph{end} of the list instead by providing a third
|
||||
|
|
|
@ -64,10 +64,10 @@ match. E.g.,
|
|||
The order of the substrings corresponds to the order in which the
|
||||
opening brackets occur.
|
||||
|
||||
A number of variables can be used to control the behaviour
|
||||
A number of variables can be used to control the behavior
|
||||
of @code{expect} (and @code{expect-strings}).
|
||||
Most have default top-level bindings to the value @code{#f},
|
||||
which produces the default behaviour.
|
||||
which produces the default behavior.
|
||||
They can be redefined at the
|
||||
top level or locally bound in a form enclosing the expect expression.
|
||||
|
||||
|
@ -142,6 +142,6 @@ of the file:
|
|||
@end lisp
|
||||
|
||||
The control variables described for @code{expect-strings} also
|
||||
influence the behaviour of @code{expect}, with the exception of
|
||||
influence the behavior of @code{expect}, with the exception of
|
||||
variables whose names begin with @code{expect-strings-}.
|
||||
@end defmac
|
||||
|
|
|
@ -1801,7 +1801,7 @@ instances of an application-defined class --- and an understanding of
|
|||
the MOP makes it much easier to explain such customizations in a precise
|
||||
way. And at a deeper level, understanding the MOP is a key part of
|
||||
understanding GOOPS, and of taking full advantage of GOOPS' power, by
|
||||
customizing the behaviour of GOOPS itself.
|
||||
customizing the behavior of GOOPS itself.
|
||||
|
||||
@menu
|
||||
* Metaobjects and the Metaobject Protocol::
|
||||
|
@ -1833,18 +1833,18 @@ Of these entities, GOOPS represents classes, generic functions and
|
|||
methods as ``metaobjects''. In other words, the values in a GOOPS
|
||||
program that describe classes, generic functions and methods, are
|
||||
themselves instances (or ``objects'') of special GOOPS classes that
|
||||
encapsulate the behaviour, respectively, of classes, generic functions,
|
||||
encapsulate the behavior, respectively, of classes, generic functions,
|
||||
and methods.
|
||||
|
||||
(The other two entities are slot definitions and instances. Slot
|
||||
definitions are not strictly instances, but every slot definition is
|
||||
associated with a GOOPS class that specifies the behaviour of the slot
|
||||
associated with a GOOPS class that specifies the behavior of the slot
|
||||
as regards accessibility and protection from garbage collection.
|
||||
Instances are of course objects in the usual sense, and there is no
|
||||
benefit from thinking of them as metaobjects.)
|
||||
|
||||
The ``metaobject protocol'' (or ``MOP'') is the specification of the
|
||||
generic functions which determine the behaviour of these metaobjects and
|
||||
generic functions which determine the behavior of these metaobjects and
|
||||
the circumstances in which these generic functions are invoked.
|
||||
|
||||
For a concrete example of what this means, consider how GOOPS calculates
|
||||
|
@ -1880,7 +1880,7 @@ performs the slot calculation.
|
|||
@end itemize
|
||||
|
||||
In other words, rather than being hardcoded in @code{define-class}, the
|
||||
default behaviour of class definition is encapsulated by generic
|
||||
default behavior of class definition is encapsulated by generic
|
||||
function methods that are specialized for the class @code{<class>}.
|
||||
|
||||
It is possible to create a new class that inherits from @code{<class>},
|
||||
|
@ -1894,7 +1894,7 @@ with the new @code{initialize} method. Thus the default slot
|
|||
calculation, as well as any other aspect of the new class's relationship
|
||||
with its superclasses, can be modified or overridden.
|
||||
|
||||
In a similar way, the behaviour of generic functions can be modified or
|
||||
In a similar way, the behavior of generic functions can be modified or
|
||||
overridden by creating a new class that inherits from the standard
|
||||
generic function class @code{<generic>}, writing appropriate methods
|
||||
that are specialized to the new class, and creating new generic
|
||||
|
@ -1907,7 +1907,7 @@ of that class.
|
|||
|
||||
Such is the power of the MOP. Note that @code{initialize} is just one
|
||||
of a large number of generic functions that can be customized to modify
|
||||
the behaviour of application objects and classes and of GOOPS itself.
|
||||
the behavior of application objects and classes and of GOOPS itself.
|
||||
Each following section covers a particular area of GOOPS functionality,
|
||||
and describes the generic functions that are relevant for customization
|
||||
of that area.
|
||||
|
@ -2419,7 +2419,7 @@ If the metaclass of the new class is something more specialized than the
|
|||
default @code{<class>}, then the type of @var{class} in the calls above
|
||||
is more specialized than @code{<class>}, and hence it becomes possible
|
||||
to define generic function methods, specialized for the new class's
|
||||
metaclass, that can modify or override the default behaviour of
|
||||
metaclass, that can modify or override the default behavior of
|
||||
@code{initialize}, @code{compute-cpl} or @code{compute-get-n-set}.
|
||||
|
||||
@code{compute-cpl} computes the class precedence list (``CPL'') for the
|
||||
|
@ -2508,9 +2508,9 @@ standard @code{initialize} method for classes whose metaclass is
|
|||
@code{<class>}. But @code{initialize} itself can also be modified, by
|
||||
defining an @code{initialize} method specialized to the new class's
|
||||
metaclass. Such a method could complete override the standard
|
||||
behaviour, by not calling @code{(next-method)} at all, but more
|
||||
behavior, by not calling @code{(next-method)} at all, but more
|
||||
typically it would perform additional class initialization steps before
|
||||
and/or after calling @code{(next-method)} for the standard behaviour.
|
||||
and/or after calling @code{(next-method)} for the standard behavior.
|
||||
|
||||
|
||||
@node Method Definition
|
||||
|
@ -2759,7 +2759,7 @@ make}). What then happens if @code{<my-class>} is redefined by calling
|
|||
|
||||
@menu
|
||||
* Redefinable Classes::
|
||||
* Default Class Redefinition Behaviour::
|
||||
* Default Class Redefinition Behavior::
|
||||
* Customizing Class Redefinition::
|
||||
@end menu
|
||||
|
||||
|
@ -2794,8 +2794,8 @@ theory. In practice, attempting to, for example, redefine
|
|||
Still, redefinition is an interesting capability when building
|
||||
long-lived resilient systems, so GOOPS does offer this facility.
|
||||
|
||||
@node Default Class Redefinition Behaviour
|
||||
@subsection Default Class Redefinition Behaviour
|
||||
@node Default Class Redefinition Behavior
|
||||
@subsection Default Class Redefinition Behavior
|
||||
|
||||
When a class is defined using @code{define-class} and the class name was
|
||||
previously defined, by default the new binding just replaces the old
|
||||
|
@ -2849,11 +2849,11 @@ updated when a class is redefined.)
|
|||
@end itemize
|
||||
|
||||
If this class redefinition strategy strikes you as rather counter-intuitive,
|
||||
bear in mind that it is derived from similar behaviour in other object
|
||||
bear in mind that it is derived from similar behavior in other object
|
||||
systems such as CLOS, and that experience in those systems has shown it to be
|
||||
very useful in practice.
|
||||
|
||||
Also bear in mind that, like most of GOOPS' default behaviour, it can
|
||||
Also bear in mind that, like most of GOOPS' default behavior, it can
|
||||
be customized@dots{}
|
||||
|
||||
@node Customizing Class Redefinition
|
||||
|
@ -2864,7 +2864,7 @@ constructs the new class metaobject as usual, then invokes the
|
|||
@code{class-redefinition} generic function with the old and new classes
|
||||
as arguments. Therefore, if the old or new classes have metaclasses
|
||||
other than the default @code{<redefinable-class>}, class redefinition
|
||||
behaviour can be customized by defining a @code{class-redefinition}
|
||||
behavior can be customized by defining a @code{class-redefinition}
|
||||
method that is specialized for the relevant metaclasses.
|
||||
|
||||
@deffn generic class-redefinition
|
||||
|
@ -2880,8 +2880,8 @@ classes. @xref{Redefinable Classes}. This default method just returns
|
|||
@end deffn
|
||||
|
||||
@deffn method class-redefinition (old <redefinable-class>) (new <redefinable-class>)
|
||||
This method implements GOOPS' default class redefinition behaviour, as
|
||||
described in @ref{Default Class Redefinition Behaviour}. Returns the
|
||||
This method implements GOOPS' default class redefinition behavior, as
|
||||
described in @ref{Default Class Redefinition Behavior}. Returns the
|
||||
metaobject for the new class definition.
|
||||
@end deffn
|
||||
|
||||
|
@ -2980,6 +2980,6 @@ instance whose class has just been changed. The default
|
|||
@code{update-instance-for-different-class} method does nothing.
|
||||
@end deffn
|
||||
|
||||
Customized change of class behaviour can be implemented by defining
|
||||
Customized change of class behavior can be implemented by defining
|
||||
@code{change-class} methods that are specialized either by the class
|
||||
of the instances to be modified or by the metaclass of the new class.
|
||||
|
|
|
@ -97,7 +97,7 @@ into @var{width} characters. By default, @var{obj} will be printed using
|
|||
@code{write}, though that behavior can be overridden via the
|
||||
@var{display?} keyword argument.
|
||||
|
||||
The default behaviour is to print depth-first, meaning that the entire
|
||||
The default behavior is to print depth-first, meaning that the entire
|
||||
remaining width will be available to each sub-expression of @var{obj} --
|
||||
e.g., if @var{obj} is a vector, each member of @var{obj}. One can attempt to
|
||||
``ration'' the available width, trying to allocate it equally to each
|
||||
|
|
|
@ -162,7 +162,7 @@ environment, setting the revealed count is not required provided the
|
|||
port is kept open (i.e., is pointed to by a live Scheme binding) while
|
||||
the file descriptor is in use.
|
||||
|
||||
To correspond with traditional Unix behaviour, three file descriptors
|
||||
To correspond with traditional Unix behavior, three file descriptors
|
||||
(0, 1, and 2) are automatically imported when a program starts up and
|
||||
assigned to the initial values of the current/standard input, output,
|
||||
and error ports, respectively. The revealed count for each is
|
||||
|
@ -414,7 +414,7 @@ descriptor underlying @var{port}, with mode string @var{modes}
|
|||
as for @ref{File Ports, open-file}. The two ports
|
||||
will share a file position and file status flags.
|
||||
|
||||
Unexpected behaviour can result if both ports are subsequently used
|
||||
Unexpected behavior can result if both ports are subsequently used
|
||||
and the original and/or duplicate ports are buffered.
|
||||
The mode string can include @code{0} to obtain an unbuffered duplicate
|
||||
port.
|
||||
|
@ -432,7 +432,7 @@ and file status flags.
|
|||
|
||||
The return value is unspecified.
|
||||
|
||||
Unexpected behaviour can result if both ports are subsequently used
|
||||
Unexpected behavior can result if both ports are subsequently used
|
||||
and the original and/or duplicate ports are buffered.
|
||||
|
||||
This procedure does not have any side effects on other ports or
|
||||
|
@ -1293,7 +1293,7 @@ stream. Otherwise, close the stream. The @code{setpwent} and
|
|||
@deffn {Scheme Procedure} getpw [user]
|
||||
@deffnx {C Function} scm_getpwuid (user)
|
||||
Look up an entry in the user database. @var{user} can be an integer,
|
||||
a string, or omitted, giving the behaviour of getpwuid, getpwnam
|
||||
a string, or omitted, giving the behavior of getpwuid, getpwnam
|
||||
or getpwent respectively.
|
||||
@end deffn
|
||||
|
||||
|
@ -1348,7 +1348,7 @@ stream. Otherwise, close the stream. The @code{setgrent} and
|
|||
@deffn {Scheme Procedure} getgr [group]
|
||||
@deffnx {C Function} scm_getgrgid (group)
|
||||
Look up an entry in the group database. @var{group} can be an integer,
|
||||
a string, or omitted, giving the behaviour of getgrgid, getgrnam
|
||||
a string, or omitted, giving the behavior of getgrgid, getgrnam
|
||||
or getgrent respectively.
|
||||
@end deffn
|
||||
|
||||
|
@ -1862,7 +1862,7 @@ has terminated or (optionally) stopped. Normally it will
|
|||
suspend the calling process until this can be done. If more than one
|
||||
child process is eligible then one will be chosen by the operating system.
|
||||
|
||||
The value of @var{pid} determines the behaviour:
|
||||
The value of @var{pid} determines the behavior:
|
||||
|
||||
@table @asis
|
||||
@item @var{pid} greater than 0
|
||||
|
|
|
@ -21,7 +21,7 @@ history entries.
|
|||
|
||||
@menu
|
||||
* Loading Readline Support:: How to load readline support into Guile.
|
||||
* Readline Options:: How to modify readline's behaviour.
|
||||
* Readline Options:: How to modify readline's behavior.
|
||||
* Readline Functions:: Programming with readline.
|
||||
@end menu
|
||||
|
||||
|
@ -44,7 +44,7 @@ activate readline's features for the REPL. If you plan to use this
|
|||
module often, you should save these to lines to your @file{.guile}
|
||||
personal startup file.
|
||||
|
||||
You will notice that the REPL's behaviour changes a bit when you have
|
||||
You will notice that the REPL's behavior changes a bit when you have
|
||||
loaded the readline module. For example, when you press Enter before
|
||||
typing in the closing parentheses of a list, you will see the
|
||||
@dfn{continuation} prompt, three dots: @code{...} This gives you a nice
|
||||
|
|
|
@ -260,7 +260,7 @@ value to the more convenient name @code{call/cc}.
|
|||
Let's understand exactly how this works. The definition creates a new
|
||||
variable @code{call/cc}, and then sets its value to the value of the
|
||||
variable @code{call-with-current-continuation}; the latter value is a
|
||||
procedure that implements the behaviour that R5RS specifies under the
|
||||
procedure that implements the behavior that R5RS specifies under the
|
||||
name ``call-with-current-continuation''. So @code{call/cc} ends up
|
||||
holding this value as well.
|
||||
|
||||
|
@ -293,7 +293,7 @@ value is a procedure. Most commonly, however, @var{procedure} is simply
|
|||
the name of a variable whose value is a procedure.
|
||||
|
||||
For example, @code{string-append} is a standard Scheme procedure whose
|
||||
behaviour is to concatenate together all the arguments, which are
|
||||
behavior is to concatenate together all the arguments, which are
|
||||
expected to be strings, that it is given. So the expression
|
||||
|
||||
@lisp
|
||||
|
@ -359,7 +359,7 @@ For example, the value of the following Scheme expression
|
|||
|
||||
@noindent
|
||||
is a newly created procedure that takes two arguments: @code{name} and
|
||||
@code{address}. The behaviour of the new procedure is determined by the
|
||||
@code{address}. The behavior of the new procedure is determined by the
|
||||
sequence of expressions and definitions in the @var{body} of the
|
||||
procedure definition. (Typically, @var{body} would use the arguments in
|
||||
some way, or else there wouldn't be any point in giving them to the
|
||||
|
@ -511,7 +511,7 @@ program as a whole.
|
|||
This section clarifies what we mean by an expression's value, by
|
||||
introducing the idea of @dfn{evaluation}. It discusses the side effects
|
||||
that evaluation can have, explains how each of the various types of
|
||||
Scheme expression is evaluated, and describes the behaviour and use of
|
||||
Scheme expression is evaluated, and describes the behavior and use of
|
||||
the Guile REPL as a mechanism for exploring evaluation. The section
|
||||
concludes with a very brief summary of Scheme's common syntactic
|
||||
expressions.
|
||||
|
@ -549,7 +549,7 @@ values, or side effects, or both.
|
|||
It is tempting to try to define more intuitively what we mean by
|
||||
``value'' and ``side effects'', and what the difference between them is.
|
||||
In general, though, this is extremely difficult. It is also
|
||||
unnecessary; instead, we can quite happily define the behaviour of a
|
||||
unnecessary; instead, we can quite happily define the behavior of a
|
||||
Scheme program by specifying how Scheme executes a program as a whole,
|
||||
and then by describing the value and side effects of evaluation for each
|
||||
type of expression individually.
|
||||
|
@ -718,7 +718,7 @@ In the outermost expression, @var{procedure} is @code{string-length} and
|
|||
@itemize @bullet
|
||||
@item
|
||||
Evaluation of @code{string-length}, which is a variable, gives a
|
||||
procedure value that implements the expected behaviour for
|
||||
procedure value that implements the expected behavior for
|
||||
``string-length''.
|
||||
|
||||
@item
|
||||
|
@ -728,7 +728,7 @@ another procedure invocation expression, means evaluating each of
|
|||
@itemize @bullet
|
||||
@item
|
||||
@code{string-append}, which gives a procedure value that implements the
|
||||
expected behaviour for ``string-append''
|
||||
expected behavior for ``string-append''
|
||||
|
||||
@item
|
||||
@code{"/home"}, which gives the string value @code{"/home"}
|
||||
|
@ -920,7 +920,7 @@ execute, Guile enters its standard Read Evaluate Print Loop --- or
|
|||
Scheme expression that the user types, evaluates it, and prints the
|
||||
resulting value.
|
||||
|
||||
The REPL is a useful mechanism for exploring the evaluation behaviour
|
||||
The REPL is a useful mechanism for exploring the evaluation behavior
|
||||
described in the previous subsection. If you type @code{string-append},
|
||||
for example, the REPL replies @code{#<primitive-procedure
|
||||
string-append>}, illustrating the relationship between the variable
|
||||
|
@ -1220,7 +1220,7 @@ of the code that calls @code{currency-string} rebinds the name
|
|||
``currency-abbreviation'' in the meanwhile.
|
||||
|
||||
The second function @code{french-currency-string} works precisely by
|
||||
taking advantage of this behaviour. It creates a new binding for the
|
||||
taking advantage of this behavior. It creates a new binding for the
|
||||
name ``currency-abbreviation'' which overrides the one established by
|
||||
the @code{defvar} form.
|
||||
|
||||
|
@ -1267,7 +1267,7 @@ the name ``currency-abbreviation'' at all, the binding is pointless.
|
|||
"USD33.44"
|
||||
@end lisp
|
||||
|
||||
This begs the question of how the Emacs Lisp behaviour can be
|
||||
This begs the question of how the Emacs Lisp behavior can be
|
||||
implemented in Scheme. In general, this is a design question whose
|
||||
answer depends upon the problem that is being addressed. In this case,
|
||||
the best answer may be that @code{currency-string} should be
|
||||
|
|
|
@ -225,7 +225,7 @@ procedure to call after loading the script, Guile will call that
|
|||
procedure with @code{(command-line)} as its argument. So a script that
|
||||
uses @code{-e} doesn't need to refer explicitly to @code{command-line}
|
||||
in its code. For example, the script above would have identical
|
||||
behaviour if it was written instead like this:
|
||||
behavior if it was written instead like this:
|
||||
|
||||
@example
|
||||
#! /usr/local/bin/guile \
|
||||
|
|
|
@ -2139,7 +2139,7 @@ Guile provides a set of primitives and SRFI-18 is one of the systems built in te
|
|||
* SRFI-18 Mutexes:: Mutual exclusion devices
|
||||
* SRFI-18 Condition variables:: Synchronizing of groups of threads
|
||||
* SRFI-18 Time:: Representation of times and durations
|
||||
* SRFI-18 Exceptions:: Signalling and handling errors
|
||||
* SRFI-18 Exceptions:: Signaling and handling errors
|
||||
@end menu
|
||||
|
||||
@node SRFI-18 Threads
|
||||
|
@ -3065,7 +3065,7 @@ specialization of @code{write}, sending output to
|
|||
The special symbol @code{<>} indicates a slot to be filled by an
|
||||
argument to the new procedure. @code{my-output-port} on the other
|
||||
hand is an expression to be evaluated and passed, ie.@: it specializes
|
||||
the behaviour of @code{write}.
|
||||
the behavior of @code{write}.
|
||||
|
||||
@table @nicode
|
||||
@item <>
|
||||
|
@ -6094,7 +6094,7 @@ These functions are in the @code{(srfi srfi-171 meta)} module and are only
|
|||
usable when you want to write your own transducers.
|
||||
|
||||
@deffn {Scheme Procedure} reduced value
|
||||
Wraps a value in a @code{<reduced>} container, signalling that the
|
||||
Wraps a value in a @code{<reduced>} container, signaling that the
|
||||
reduction should stop.
|
||||
@end deffn
|
||||
|
||||
|
|
|
@ -884,7 +884,7 @@
|
|||
; uses union/find elements with two info fields
|
||||
; a type variable has exactly four fields:
|
||||
; car: TVar (the parent field; initially null)
|
||||
; cadr: Number (the rank field; is always nonnegative)
|
||||
; cadr: Number (the rank field; is always non-negative)
|
||||
; caddr: Symbol (the type variable identifier; used only for printing)
|
||||
; cdddr: Type (the leq field; initially null)
|
||||
(gen-element (cons (gen-id) '())))
|
||||
|
|
|
@ -16067,7 +16067,7 @@
|
|||
; Returns a length-4 bytevector.
|
||||
;
|
||||
; M may be an exact integer or a length-4 bytevector.
|
||||
; N must be an exact nonnegative integer; it's interpreted modulo 33.
|
||||
; N must be an exact non-negative integer; it's interpreted modulo 33.
|
||||
|
||||
(define (asm:lsh m n)
|
||||
(if (not (bytevector? m))
|
||||
|
@ -16098,7 +16098,7 @@
|
|||
; Returns a length-4 bytevector.
|
||||
;
|
||||
; M may be an exact integer or a length-4 bytevector.
|
||||
; N must be an exact nonnegative integer; it's interpreted modulo 33.
|
||||
; N must be an exact non-negative integer; it's interpreted modulo 33.
|
||||
|
||||
(define (asm:rshl m n)
|
||||
(if (not (bytevector? m))
|
||||
|
@ -16129,7 +16129,7 @@
|
|||
; high end. Returns a length-4 bytevector.
|
||||
;
|
||||
; M may be an exact integer or a length-4 bytevector.
|
||||
; N must be an exact nonnegative integer; it's interpreted modulo 33.
|
||||
; N must be an exact non-negative integer; it's interpreted modulo 33.
|
||||
|
||||
(define asm:rsha
|
||||
(let ((ones (asm:bv #xff #xff #xff #xff)))
|
||||
|
@ -16240,7 +16240,7 @@
|
|||
|
||||
; Extract the n low-order bits of m.
|
||||
; m may be an exact integer or a length-4 bytevector.
|
||||
; n must be an exact nonnegative integer, interpreted modulo 32.
|
||||
; n must be an exact non-negative integer, interpreted modulo 32.
|
||||
; Returns length-4 bytevector.
|
||||
;
|
||||
; Does not depend on endian-ness.
|
||||
|
@ -16255,7 +16255,7 @@
|
|||
|
||||
; Extract the n high-order bits of m.
|
||||
; m may be an exact integer or a length-4 bytevector.
|
||||
; n must be an exact nonnegative integer, interpreted modulo 33.
|
||||
; n must be an exact non-negative integer, interpreted modulo 33.
|
||||
; Returns length-4 bytevector with the high-order bits of m at low end.
|
||||
;
|
||||
; Does not depend on endian-ness.
|
||||
|
@ -16553,7 +16553,7 @@
|
|||
;
|
||||
; version a fixnum (constant) - heap type version number
|
||||
; roots an assoc list that maps root names to values
|
||||
; top an exact nonnegative integer: the address of the
|
||||
; top an exact non-negative integer: the address of the
|
||||
; next byte to be emitted
|
||||
; symbol-table a symbol table abstract data type
|
||||
; extra any value - a client-extension field
|
||||
|
@ -20735,7 +20735,7 @@
|
|||
|
||||
; Strings
|
||||
|
||||
; RESULT must have nonnegative fixnum.
|
||||
; RESULT must have non-negative fixnum.
|
||||
; RS2 must have character.
|
||||
|
||||
(define-primop 'make-string
|
||||
|
@ -23056,7 +23056,7 @@
|
|||
; A `decoded-instruction' is a list where the car is a mnemonic and
|
||||
; the operands are appropriate for that mnemonic.
|
||||
;
|
||||
; A `mnemonic' is an exact nonnegative integer. It encodes the name of
|
||||
; A `mnemonic' is an exact non-negative integer. It encodes the name of
|
||||
; the instruction as well as its attributes (operand pattern and instruction
|
||||
; type). See below for specific operations on mnemonics.
|
||||
|
||||
|
|
|
@ -16067,7 +16067,7 @@
|
|||
; Returns a length-4 bytevector.
|
||||
;
|
||||
; M may be an exact integer or a length-4 bytevector.
|
||||
; N must be an exact nonnegative integer; it's interpreted modulo 33.
|
||||
; N must be an exact non-negative integer; it's interpreted modulo 33.
|
||||
|
||||
(define (asm:lsh m n)
|
||||
(if (not (bytevector? m))
|
||||
|
@ -16098,7 +16098,7 @@
|
|||
; Returns a length-4 bytevector.
|
||||
;
|
||||
; M may be an exact integer or a length-4 bytevector.
|
||||
; N must be an exact nonnegative integer; it's interpreted modulo 33.
|
||||
; N must be an exact non-negative integer; it's interpreted modulo 33.
|
||||
|
||||
(define (asm:rshl m n)
|
||||
(if (not (bytevector? m))
|
||||
|
@ -16129,7 +16129,7 @@
|
|||
; high end. Returns a length-4 bytevector.
|
||||
;
|
||||
; M may be an exact integer or a length-4 bytevector.
|
||||
; N must be an exact nonnegative integer; it's interpreted modulo 33.
|
||||
; N must be an exact non-negative integer; it's interpreted modulo 33.
|
||||
|
||||
(define asm:rsha
|
||||
(let ((ones (asm:bv #xff #xff #xff #xff)))
|
||||
|
@ -16240,7 +16240,7 @@
|
|||
|
||||
; Extract the n low-order bits of m.
|
||||
; m may be an exact integer or a length-4 bytevector.
|
||||
; n must be an exact nonnegative integer, interpreted modulo 32.
|
||||
; n must be an exact non-negative integer, interpreted modulo 32.
|
||||
; Returns length-4 bytevector.
|
||||
;
|
||||
; Does not depend on endian-ness.
|
||||
|
@ -16255,7 +16255,7 @@
|
|||
|
||||
; Extract the n high-order bits of m.
|
||||
; m may be an exact integer or a length-4 bytevector.
|
||||
; n must be an exact nonnegative integer, interpreted modulo 33.
|
||||
; n must be an exact non-negative integer, interpreted modulo 33.
|
||||
; Returns length-4 bytevector with the high-order bits of m at low end.
|
||||
;
|
||||
; Does not depend on endian-ness.
|
||||
|
@ -16553,7 +16553,7 @@
|
|||
;
|
||||
; version a fixnum (constant) - heap type version number
|
||||
; roots an assoc list that maps root names to values
|
||||
; top an exact nonnegative integer: the address of the
|
||||
; top an exact non-negative integer: the address of the
|
||||
; next byte to be emitted
|
||||
; symbol-table a symbol table abstract data type
|
||||
; extra any value - a client-extension field
|
||||
|
@ -20735,7 +20735,7 @@
|
|||
|
||||
; Strings
|
||||
|
||||
; RESULT must have nonnegative fixnum.
|
||||
; RESULT must have non-negative fixnum.
|
||||
; RS2 must have character.
|
||||
|
||||
(define-primop 'make-string
|
||||
|
@ -23056,7 +23056,7 @@
|
|||
; A `decoded-instruction' is a list where the car is a mnemonic and
|
||||
; the operands are appropriate for that mnemonic.
|
||||
;
|
||||
; A `mnemonic' is an exact nonnegative integer. It encodes the name of
|
||||
; A `mnemonic' is an exact non-negative integer. It encodes the name of
|
||||
; the instruction as well as its attributes (operand pattern and instruction
|
||||
; type). See below for specific operations on mnemonics.
|
||||
|
||||
|
|
|
@ -194,7 +194,7 @@ scm_double_cell (scm_t_bits car, scm_t_bits cbr,
|
|||
advantage of strict C aliasing rules which say that it's OK to
|
||||
interchange the initialization above and the one below when the
|
||||
pointer types appear to differ sufficiently. We don't want that,
|
||||
of course. GCC allows this behaviour to be disabled with the
|
||||
of course. GCC allows this behavior to be disabled with the
|
||||
-fno-strict-aliasing option, but would also need to be supplied
|
||||
by Guile users. Instead, the following statements prevent the
|
||||
reordering.
|
||||
|
@ -227,7 +227,7 @@ scm_words (scm_t_bits car, uint32_t n_words)
|
|||
advantage of strict C aliasing rules which say that it's OK to
|
||||
interchange the initialization above and the one below when the
|
||||
pointer types appear to differ sufficiently. We don't want that,
|
||||
of course. GCC allows this behaviour to be disabled with the
|
||||
of course. GCC allows this behavior to be disabled with the
|
||||
-fno-strict-aliasing option, but would also need to be supplied
|
||||
by Guile users. Instead, the following statements prevent the
|
||||
reordering.
|
||||
|
|
|
@ -77,7 +77,7 @@ SCM_DEFINE (scm_redirect_port, "redirect-port", 2, 0, 0,
|
|||
"After the redirection the two ports will share a file position\n"
|
||||
"and file status flags.\n\n"
|
||||
"The return value is unspecified.\n\n"
|
||||
"Unexpected behaviour can result if both ports are subsequently used\n"
|
||||
"Unexpected behavior can result if both ports are subsequently used\n"
|
||||
"and the original and/or duplicate ports are buffered.\n\n"
|
||||
"This procedure does not have any side effects on other ports or\n"
|
||||
"revealed counts.")
|
||||
|
|
|
@ -308,7 +308,7 @@ SCM_DEFINE (scm_append_x, "append!", 0, 0, 1,
|
|||
|
||||
SCM_DEFINE (scm_last_pair, "last-pair", 1, 0, 0,
|
||||
(SCM lst),
|
||||
"Return the last pair in @var{lst}, signalling an error if\n"
|
||||
"Return the last pair in @var{lst}, signaling an error if\n"
|
||||
"@var{lst} is circular.")
|
||||
#define FUNC_NAME s_scm_last_pair
|
||||
{
|
||||
|
|
|
@ -55,7 +55,7 @@
|
|||
* Some definitions:
|
||||
*
|
||||
* Run time options in Guile are arranged in groups. Each group
|
||||
* affects a certain aspect of the behaviour of the library.
|
||||
* affects a certain aspect of the behavior of the library.
|
||||
*
|
||||
* An "options interface procedure" manages one group of options. It
|
||||
* can be used to check or set options, or to get documentation for
|
||||
|
|
|
@ -389,7 +389,7 @@ SCM_DEFINE (scm_setgroups, "setgroups", 1, 0, 0,
|
|||
SCM_DEFINE (scm_getpwuid, "getpw", 0, 1, 0,
|
||||
(SCM user),
|
||||
"Look up an entry in the user database. @var{user} can be an\n"
|
||||
"integer, a string, or omitted, giving the behaviour of\n"
|
||||
"integer, a string, or omitted, giving the behavior of\n"
|
||||
"@code{getpwuid}, @code{getpwnam} or @code{getpwent}\n"
|
||||
"respectively.")
|
||||
#define FUNC_NAME s_scm_getpwuid
|
||||
|
@ -459,7 +459,7 @@ SCM_DEFINE (scm_setpwent, "setpw", 0, 1, 0,
|
|||
SCM_DEFINE (scm_getgrgid, "getgr", 0, 1, 0,
|
||||
(SCM name),
|
||||
"Look up an entry in the group database. @var{name} can be an\n"
|
||||
"integer, a string, or omitted, giving the behaviour of\n"
|
||||
"integer, a string, or omitted, giving the behavior of\n"
|
||||
"@code{getgrgid}, @code{getgrnam} or @code{getgrent}\n"
|
||||
"respectively.")
|
||||
#define FUNC_NAME s_scm_getgrgid
|
||||
|
@ -725,7 +725,7 @@ SCM_DEFINE (scm_waitpid, "waitpid", 1, 1, 0,
|
|||
"has terminated or (optionally) stopped. Normally it will\n"
|
||||
"suspend the calling process until this can be done. If more than one\n"
|
||||
"child process is eligible then one will be chosen by the operating system.\n\n"
|
||||
"The value of @var{pid} determines the behaviour:\n\n"
|
||||
"The value of @var{pid} determines the behavior:\n\n"
|
||||
"@table @r\n"
|
||||
"@item @var{pid} greater than 0\n"
|
||||
"Request status information from the specified child process.\n"
|
||||
|
|
|
@ -902,7 +902,7 @@ enum scm_mutex_kind {
|
|||
/* An unowned mutex is like a standard mutex, except that it can be
|
||||
unlocked by any thread. A corrolary of this behavior is that a
|
||||
thread's attempt to lock a mutex that it already owns will block
|
||||
instead of signalling an error, as it could be that some other
|
||||
instead of signaling an error, as it could be that some other
|
||||
thread unlocks the mutex, allowing the owner thread to proceed.
|
||||
This kind of mutex is a bit strange and is here for use by
|
||||
SRFI-18. */
|
||||
|
|
|
@ -2750,8 +2750,8 @@ are not themselves bound to a defined value."
|
|||
|
||||
(define (module-symbol-local-binding m v . opt-val)
|
||||
"Return the binding of variable V specified by name within module M,
|
||||
signalling an error if the variable is unbound. If the OPT-VALUE is
|
||||
passed, then instead of signalling an error, return OPT-VALUE."
|
||||
signaling an error if the variable is unbound. If the OPT-VALUE is
|
||||
passed, then instead of signaling an error, return OPT-VALUE."
|
||||
(let ((var (module-local-variable m v)))
|
||||
(if (and var (variable-bound? var))
|
||||
(variable-ref var)
|
||||
|
@ -2761,8 +2761,8 @@ passed, then instead of signalling an error, return OPT-VALUE."
|
|||
|
||||
(define (module-symbol-binding m v . opt-val)
|
||||
"Return the binding of variable V specified by name within module M,
|
||||
signalling an error if the variable is unbound. If the OPT-VALUE is
|
||||
passed, then instead of signalling an error, return OPT-VALUE."
|
||||
signaling an error if the variable is unbound. If the OPT-VALUE is
|
||||
passed, then instead of signaling an error, return OPT-VALUE."
|
||||
(let ((var (module-variable m v)))
|
||||
(if (and var (variable-bound? var))
|
||||
(variable-ref var)
|
||||
|
@ -3452,7 +3452,7 @@ error if selected binding does not exist in the used module."
|
|||
;; FIXME: Avoid use of `apply'.
|
||||
(apply module-autoload! module autoloads)
|
||||
(let ((duplicates (or duplicates
|
||||
;; Avoid stompling a previously installed
|
||||
;; Avoid stomping a previously installed
|
||||
;; duplicates handlers if possible.
|
||||
(and (not (module-duplicates-handlers module))
|
||||
;; Note: If you change this default,
|
||||
|
|
|
@ -196,7 +196,7 @@
|
|||
;;
|
||||
;; lambda* creates a procedure that takes optional arguments. These
|
||||
;; are specified by putting them inside brackets at the end of the
|
||||
;; paramater list, but before any dotted rest argument. For example,
|
||||
;; parameter list, but before any dotted rest argument. For example,
|
||||
;; (lambda* (a b #:optional c d . e) '())
|
||||
;; creates a procedure with fixed arguments a and b, optional arguments c
|
||||
;; and d, and rest argument e. If the optional arguments are omitted
|
||||
|
|
|
@ -461,7 +461,7 @@ never again be used for a read or write operation."
|
|||
|
||||
(define* (call-with-output-file file proc #:key (binary #f) (encoding #f))
|
||||
"PROC should be a procedure of one argument, and FILE should be a
|
||||
string naming a file. The behaviour is unspecified if the file
|
||||
string naming a file. The behavior is unspecified if the file
|
||||
already exists. These procedures call PROC
|
||||
with one argument: the port obtained by opening the named file for
|
||||
input or output. If the file cannot be opened, an error is
|
||||
|
|
|
@ -320,7 +320,7 @@ into @var{width} characters. By default, @var{x} will be printed using
|
|||
@code{write}, though that behavior can be overriden via the
|
||||
@var{display?} keyword argument.
|
||||
|
||||
The default behaviour is to print depth-first, meaning that the entire
|
||||
The default behavior is to print depth-first, meaning that the entire
|
||||
remaining width will be available to each sub-expression of @var{x} --
|
||||
e.g., if @var{x} is a vector, each member of @var{x}. One can attempt to
|
||||
\"ration\" the available width, trying to allocate it equally to each
|
||||
|
|
|
@ -481,7 +481,7 @@
|
|||
;; (lexical . <var>) lexical variables
|
||||
;; (ellipsis . <identifier>) custom ellipsis
|
||||
;; (displaced-lexical) displaced lexicals
|
||||
;; <level> ::= <nonnegative integer>
|
||||
;; <level> ::= <non-negative integer>
|
||||
;; <var> ::= variable returned by build-lexical-var
|
||||
|
||||
;; a macro is a user-defined syntactic-form. a core is a
|
||||
|
|
|
@ -37,7 +37,7 @@
|
|||
|
||||
;;; For parsing circular structures, we keep track of definitions in a
|
||||
;;; hash-map that maps the id's to their values. When defining a new
|
||||
;;; id, though, we immediatly fill the slot with a promise before
|
||||
;;; id, though, we immediately fill the slot with a promise before
|
||||
;;; parsing and setting the real value, because it must already be
|
||||
;;; available at that time in case of a circular reference. The promise
|
||||
;;; refers to a local variable that will be set when the real value is
|
||||
|
|
|
@ -1124,7 +1124,7 @@ in the frame with for the lambda-case clause @var{clause}."
|
|||
(0
|
||||
(emit-load-static-procedure asm dst label))
|
||||
(nfree
|
||||
;; Stage closure in 0 to avoid stompling captured free
|
||||
;; Stage closure in 0 to avoid stomping captured free
|
||||
;; vars.
|
||||
(emit-allocate-closure asm 0 nfree label 1)
|
||||
(init-free-vars 0 free-vars env 1 2)
|
||||
|
@ -1148,7 +1148,7 @@ in the frame with for the lambda-case clause @var{clause}."
|
|||
frame-size)))
|
||||
|
||||
(($ <primcall> src (? variadic-constructor? name) args)
|
||||
;; Stage result in 0 to avoid stompling args.
|
||||
;; Stage result in 0 to avoid stomping args.
|
||||
(let ((args (for-args args env)))
|
||||
(maybe-emit-source src)
|
||||
(match name
|
||||
|
|
|
@ -84,7 +84,7 @@
|
|||
|
||||
(define (build-options-lookup options)
|
||||
"Answer an `equal?' Guile hash-table that maps OPTIONS' names back
|
||||
to the containing options, signalling an error if a name is
|
||||
to the containing options, signaling an error if a name is
|
||||
encountered more than once."
|
||||
(let ((lookup (make-hash-table (* 2 (length options)))))
|
||||
(for-each
|
||||
|
|
|
@ -546,7 +546,7 @@ left-to-right."
|
|||
|
||||
(define vector-count
|
||||
(case-lambda
|
||||
"(vector-count pred? vec1 vec2 ...) -> exact nonnegative integer
|
||||
"(vector-count pred? vec1 vec2 ...) -> exact non-negative integer
|
||||
|
||||
Count the number of indices i for which (PRED? VEC1[i] VEC2[i] ...)
|
||||
returns true, where i is less than the length of the shortest vector
|
||||
|
@ -586,7 +586,7 @@ passed."
|
|||
|
||||
(define vector-index
|
||||
(case-lambda
|
||||
"(vector-index pred? vec1 vec2 ...) -> exact nonnegative integer or #f
|
||||
"(vector-index pred? vec1 vec2 ...) -> exact non-negative integer or #f
|
||||
|
||||
Find and return the index of the first elements in VEC1 VEC2 ... that
|
||||
satisfy PRED?. If no matching element is found by the end of the
|
||||
|
@ -624,7 +624,7 @@ shortest vector, return #f."
|
|||
|
||||
(define vector-index-right
|
||||
(case-lambda
|
||||
"(vector-index-right pred? vec1 vec2 ...) -> exact nonnegative integer or #f
|
||||
"(vector-index-right pred? vec1 vec2 ...) -> exact non-negative integer or #f
|
||||
|
||||
Find and return the index of the last elements in VEC1 VEC2 ... that
|
||||
satisfy PRED?, searching from right-to-left. If no matching element
|
||||
|
@ -662,7 +662,7 @@ is found before the end of the shortest vector, return #f."
|
|||
|
||||
(define vector-skip
|
||||
(case-lambda
|
||||
"(vector-skip pred? vec1 vec2 ...) -> exact nonnegative integer or #f
|
||||
"(vector-skip pred? vec1 vec2 ...) -> exact non-negative integer or #f
|
||||
|
||||
Find and return the index of the first elements in VEC1 VEC2 ... that
|
||||
do not satisfy PRED?. If no matching element is found by the end of
|
||||
|
@ -700,7 +700,7 @@ the shortest vector, return #f."
|
|||
|
||||
(define vector-skip-right
|
||||
(case-lambda
|
||||
"(vector-skip-right pred? vec1 vec2 ...) -> exact nonnegative integer or #f
|
||||
"(vector-skip-right pred? vec1 vec2 ...) -> exact non-negative integer or #f
|
||||
|
||||
Find and return the index of the last elements in VEC1 VEC2 ... that
|
||||
do not satisfy PRED?, searching from right-to-left. If no matching
|
||||
|
@ -748,7 +748,7 @@ element is found before the end of the shortest vector, return #f."
|
|||
((positive? c) (loop lo i))
|
||||
((negative? c) (loop (+ i 1) hi)))))))
|
||||
(case-lambda
|
||||
"(vector-binary-search vec value cmp [start [end]]) -> exact nonnegative integer or #f
|
||||
"(vector-binary-search vec value cmp [start [end]]) -> exact non-negative integer or #f
|
||||
|
||||
Find and return an index of VEC between START and END whose value is
|
||||
VALUE using a binary search. If no matching element is found, return
|
||||
|
|
|
@ -319,7 +319,7 @@ than @code{statprof-stop}, @code{#f} otherwise."
|
|||
|
||||
;; Do not call this from statprof internal functions -- user only.
|
||||
(define* (statprof-stop #:optional (state (ensure-profiler-state)))
|
||||
"Stop the profiler.@code{}"
|
||||
"Stop the profiler."
|
||||
;; After some head-scratching, I don't *think* I need to mask/unmask
|
||||
;; signals here, but if I'm wrong, please let me know.
|
||||
(set-profile-level! state (- (profile-level state) 1))
|
||||
|
|
|
@ -20,7 +20,7 @@
|
|||
|
||||
;;; Commentary:
|
||||
;;
|
||||
;;Routines to generare @code{stexi} documentation for objects and
|
||||
;;Routines to generate @code{stexi} documentation for objects and
|
||||
;;modules.
|
||||
;;
|
||||
;;Note that in this context, an @dfn{object} is just a value associated
|
||||
|
|
|
@ -476,7 +476,7 @@
|
|||
(call-with-stack-overflow-handler 2.0
|
||||
trigger-overflow trigger-overflow))
|
||||
|
||||
(pass-if-exception "limit should be nonnegative"
|
||||
(pass-if-exception "limit should be non-negative"
|
||||
exception:out-of-range
|
||||
(call-with-stack-overflow-handler -1
|
||||
trigger-overflow trigger-overflow))
|
||||
|
@ -517,7 +517,7 @@
|
|||
(call-with-stack-overflow-handler 1000
|
||||
trigger-overflow
|
||||
(lambda () 2.0)))
|
||||
(pass-if-exception "overflow handler should be nonnegative"
|
||||
(pass-if-exception "overflow handler should be non-negative"
|
||||
exception:out-of-range
|
||||
(call-with-stack-overflow-handler 1000
|
||||
trigger-overflow
|
||||
|
|
|
@ -140,7 +140,7 @@
|
|||
(gc)
|
||||
(fluid? (g))))
|
||||
|
||||
(pass-if-exception "fluid-ref* depth must be nonnegative"
|
||||
(pass-if-exception "fluid-ref* depth must be non-negative"
|
||||
exception:out-of-range
|
||||
(fluid-ref* (make-fluid) -1))
|
||||
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue