Commit 8812ba21 authored by Marius Gerbershagen's avatar Marius Gerbershagen

doc: fix various typos and remove use of legacy names in examples

parent cd86ac50
......@@ -39,6 +39,6 @@ Moreover if bytecompiled function is a closure then its structure is
@subsection Bytecode disassembler
@defun{si:bc-split} {@var{funciton}}
@defun{si:bc-split} {@var{function}}
Returns five values: lex, bytecodes, data and name.
@end defun
......@@ -26,7 +26,7 @@ ECL internal C files are preprocessed with the [@ref{Defun
preprocessor}]. This results in the ability to use somewhat unusual
syntax in the C source files like @verb{|defun|} with the
@verb{|&optional|}, @verb{|&rest|}, @verb{|&key|} and @verb{|&aux|}
arguments as well as returning multiple values from the funciton using
arguments as well as returning multiple values from the function using
@verb{|@(return)|}..
Style used in C/C++ files is 2 space indent, no tabs, similar to
......
......@@ -95,7 +95,7 @@ Comment on the example if necessary.
@subsubheading Side effects @c Omit section if none
Side effects listed
@subsubheading Affected by @c Omit section if none
For instance: if the user has some privigiles on the system
For instance: if the user has some privileges on the system
@end defun
@end verbatim
......
......@@ -472,7 +472,7 @@ Boolean indicating if it is displaced.
@item x->vector.dim
The maximum number of elements.
@item x->vector.fillp
Actual numer of elements in the vector or @code{fill pointer}.
Actual number of elements in the vector or @code{fill pointer}.
@item x->vector.self
Union of pointers of different types. You should choose the right
pointer depending on @var{x->vector.elttype}.
......@@ -497,7 +497,7 @@ The maximum number of elements.
Array with the dimensions of the array. The elements range from
@code{x->array.dim[0]} to @code{x->array.dim[x->array.rank-1]}.
@item x->array.fillp
Actual numer of elements in the array or @code{fill pointer}.
Actual number of elements in the array or @code{fill pointer}.
@item x->array.self
Union of pointers of different types. You should choose the right
pointer depending on @var{x->array.elttype}.
......@@ -518,7 +518,7 @@ some of those types together with the C constant that denotes that type:
@code{ecl_aet_object}
@item BASE-CHAR
@code{ecl_aet_object}
@item SIGNLE-FLOAT
@item SINGLE-FLOAT
@code{ecl_aet_sf}
@item DOUBLE-FLOAT
@code{ecl_aet_df}
......@@ -783,7 +783,7 @@ si_safe_eval(form, ECL_NIL, 3); /* on error function will return 3 */
@cppindex si_make_lambda
@deftypefun cl_object si_make_lambda (cl_object name, cl_object def)
Builds an interpreted lisp function with name given by the symbol name
and body given by def.
and body given by @code{def}.
@subheading Example
@exindex @code{si_make_lambda} building functions
......
......@@ -43,7 +43,7 @@ incorporated during the evolution of the primary compiler.
@subheading Old MIT loop
Commit @code{5042589043a7be853b7f85fd7a996747412de6b4}. This old loop
implementation has got superseeded by the one incorporated from
implementation has got superseded by the one incorporated from
Symbolics LOOP in 2001.
@subheading Support for bignum arithmetic (earith.d)
......@@ -53,7 +53,7 @@ contains multiplication and division routines (assembler and a
portable implementation).
@subheading Unification module
Commit @code{6ff5d20417a21a76846c4b28e532aac097f03109}. Old unifiction
Commit @code{6ff5d20417a21a76846c4b28e532aac097f03109}. Old unification
module (logic programming) from EcoLisp times.
@subheading Hierarchical packages
......
......@@ -71,7 +71,7 @@
@tab defun preprocessor
@item ecl_constants.h
@tab contstant values for all_symbols.d
@tab constant values for all_symbols.d
@item features.h
@tab names of features compiled into ECL
......@@ -122,7 +122,7 @@
@tab macros and environment
@item main.d
@tab ecl boot proccess
@tab ecl boot process
@item Makefile.in
@tab Makefile for ECL core library
......
......@@ -230,12 +230,13 @@ main(int argc, char **argv)
@end verbatim
@end example
Because the program itself does not know the type of the init function,
a prototype declaration is inserted. After booting up the lisp
environment, it invokes @code{init_hello_goodbye} via
@code{read_VV}. @code{init_hello_goodbye} takes an argument, and read_VV
supplies an appropriate one. Now that the initialization is finished, we
can use functions and other stuffs defined in the library.
Because the program itself does not know the type of the init
function, a prototype declaration is inserted. After booting up the
lisp environment, it invokes @code{init_hello_goodbye} via
@code{read_VV}. @code{init_hello_goodbye} takes an argument, and
@code{read_VV} supplies an appropriate one. Now that the
initialization is finished, we can use functions and other stuff
defined in the library.
@node Shared library
@subsubsection Shared library
......
......@@ -3,7 +3,7 @@
@defun{close} {@var{stream} @keys{} :abort}
If @var{stream} isn't a stream close will ``let to specialize
itself''. This decision ahs been taken mainly for the compatibility
reasons with some libraries.
Unlike the other Gray stream functions, @code{close} is not
specialized on @code{t} for @var{stream}. This decision has been taken
mainly for the compatibility reasons with some libraries.
@end defun
......@@ -19,7 +19,7 @@ In this section we will discuss garbage collection, how ECL configures and uses
@node Boehm-Weiser garbage collector
@subsection Boehm-Weiser garbage collector
First of all, the garbage collector must be able to determine which objects are alive and which are not. In other words, the collector must able to find all references to an object. One possiblity would be to know where all variables of a program reside, and where is the stack of the program and its size, and parse all data there, discriminating references to lisp objects. To do this precisely one would need a very precise control of the data and stack segments, as well as how objects are laid out by the C compiler. This is beyond ECL's scope and wishes and it can make coexistence with other libraries (C++, Fortran, etc) difficult.
First of all, the garbage collector must be able to determine which objects are alive and which are not. In other words, the collector must able to find all references to an object. One possibility would be to know where all variables of a program reside, and where is the stack of the program and its size, and parse all data there, discriminating references to lisp objects. To do this precisely one would need a very precise control of the data and stack segments, as well as how objects are laid out by the C compiler. This is beyond ECL's scope and wishes and it can make coexistence with other libraries (C++, Fortran, etc) difficult.
The Boehm-Weiser garbage collector, on the other hand, is a conservative garbage collector. When scanning memory looking for references to live data, it guesses, conservatively, whether a word is a pointer or not. In case of doubt it will consider it to be a pointer and add it to the list of live objects. This may cause certain objects to be retained longer than what an user might expect but, in our experience, this is the best of both worlds and ECL uses certain strategies to minimize the amount of misinterpreted data.
......@@ -30,7 +30,7 @@ More precisely, ECL uses the garbage collector with the following settings:
The collector will not scan the data sectors. If you embed ECL in another program, or link libraries with ECL, you will have to notify ECL which variables point to lisp objects.
@item
The collector is configured to ignore pointers that point to the middle of allocated objects. This minimizes the risk of misinterpreting integers as pointers to live obejcts.
The collector is configured to ignore pointers that point to the middle of allocated objects. This minimizes the risk of misinterpreting integers as pointers to live objects.
@item
It is possible to register finalizers that are invoked when an object is destroyed, but for that you should use ECL's API and understand the restriction described later in @ref{Finalization}.
......
......@@ -50,7 +50,7 @@ This condition is signaled when ECL exhausts the @code{ext:heap-size} limit from
@item
If the heap size had a finite limit, ECL offers the user the chance to resize it, issuing a restartable condition. The user may at this point use @code{(ext:set-limit 'ext:heap-size 0)} to remove the heap limit and avoid further messages, or use the @code{(continue)} restart to let ECL enlarge the heap by some amount.
@item
Independently of the heap size limit, if ECL finds that ther is no space to free or to grow, ECL simply quits. There will be no chance to do some cleanup because there is no way to cons any additional data.
Independently of the heap size limit, if ECL finds that there is no space to free or to grow, ECL simply quits. There will be no chance to do some cleanup because there is no way to cons any additional data.
@end itemize
@end deftp
......
......@@ -11,9 +11,9 @@ The Meta-Object Protocol is an extension to Common Lisp which provides rules, fu
The Meta-Object Protocol associated to Common Lisp's object system was introduced in a famous book, The Art of the Metaobject Protocol AMOP (@xref{Bibliography}), which was probably intended for the ANSI (@xref{Bibliography}) specification but was drop out because of its revolutionary and then not too well tested ideas.
The AMOP is present, in one way or another, in most Common Lisp implementations, eithr using proprietary systems or because their implementation of CLOS descended from PCL (Portable CommonLoops). It has thus become a de facto standard and ECL should not be without it.
The AMOP is present, in one way or another, in most Common Lisp implementations, either using proprietary systems or because their implementation of CLOS descended from PCL (Portable CommonLoops). It has thus become a de facto standard and ECL should not be without it.
Unfortunately ECL's own implemention originally contained only a subset of the AMOP. This was a clever decision at the time, since the focus was on performance and on producing a stable and lean implementation of Common Lisp. Nowadays it is however not an option, specially given that most of the AMOP can be implemented with little cost for both the implementor and the user.
Unfortunately ECL's own implementation originally contained only a subset of the AMOP. This was a clever decision at the time, since the focus was on performance and on producing a stable and lean implementation of Common Lisp. Nowadays it is however not an option, specially given that most of the AMOP can be implemented with little cost for both the implementor and the user.
So ECL has an almost complete implementation of the AMOP. However, since it was written from scratch and progressed according to user's request and our own innovations, there might still be some missing functionality which we expect to correct in the near future. Please report any feature you miss as a bug through the appropriate channels.
......
......@@ -41,7 +41,7 @@ Original list of command line arguments. This function returns the
list of command line arguments passed to either ECL or the program it
was embedded in. The output is a list of strings and it corresponds to
the argv vector in a C program. Typically, the first argument is the
name of the program as it was invoked. You should not count on ths
name of the program as it was invoked. You should not count on the
filename to be resolved.
@end defun
......@@ -86,7 +86,7 @@ remaining arguments.
@defvr opt :NOLOADRC
@defvrx opt :LOADRC
Determine whether the lisp initalization file
Determine whether the lisp initialization file
@code{(ext:*lisp-init-file-list*)} will be loaded before processing
all forms.
@end defvr
......@@ -95,15 +95,15 @@ all forms.
parses all the command line arguments, except for the first one, which
is assumed to contain the program name. Each of these arguments is
matched against the rules, sequentially, until one of the patterns
succeeeds.
succeeds.
A special name @code{*DEFAULT*}, matches any unknown command line
option. If there is no @code{*DEFAULT*} rule and no match is found, an
error is signalled. For each rule that succeeds, the function
error is signaled. For each rule that succeeds, the function
constructs a lisp statement using the template.
After all arguments have been processed,
@code{ext:process-command-args}, and there were no occurences of
@code{ext:process-command-args}, and there were no occurrences of
@code{:noloadrc}, one of the files listed in
@code{ext:*lisp-init-file-list*} will be loaded. Finally, the list of
lisp statements will be evaluated.
......@@ -165,7 +165,7 @@ Returns process PID or @code{nil} if already finished.
@defun ext:external-process-status process
Updates process status. @code{ext:external-process-status} calls
@code{ext:external-process-wait} if proces has not finished yet
@code{ext:external-process-wait} if process has not finished yet
(non-blocking call). Returns two values:
@code{status} - member of @code{(:abort :error :exited :signalled
......@@ -175,7 +175,7 @@ Updates process status. @code{ext:external-process-status} calls
it is a signal code. Otherwise NIL.
@end defun
@defun ext:external-process-wait proces wait
@defun ext:external-process-wait process wait
If the second argument is non-NIL, function blocks until external
process is finished. Otherwise status is updated. Returns two values
(see @code{ext:external-process-status}).
......
......@@ -190,7 +190,7 @@ Removing an existing package local nickname to a package.
@lspindex ext:package-locked-p
@defun ext:package-locked-p package
Returns @code{t} when @code{package} is locked, @code{nil}
otherwise. Signals an error if @code{package} doesnt designate a valid
otherwise. Signals an error if @code{package} doesn't designate a valid
package.
@end defun
......
......@@ -43,7 +43,7 @@ The first family of signals are generated by the floating point processing hardw
The second family of signals may seem rare, but unfortunately they still happen quite often. One scenario is wrong code that handles memory directly via FFI. Another one is undetected stack overflows, which typically result in access to protected memory regions. Finally, a very common cause of these kind of exceptions is invoking a function that has been compiled with very low security settings with arguments that are not of the expected type -- for instance, passing a float when a structure is expected.
The third family is related to the multiprocessing capabilities in Common Lisp systems and more precisely to the mp:interrupt-process function which is used to kill, interrupt and inspect arbitrary threads. In POSIX systems ECL informs a given thread about the need to interrupt its execution by sending a particular signal from the set which is available to the user.
The third family is related to the multiprocessing capabilities in Common Lisp systems and more precisely to the @code{mp:interrupt-process} function which is used to kill, interrupt and inspect arbitrary threads. In POSIX systems ECL informs a given thread about the need to interrupt its execution by sending a particular signal from the set which is available to the user.
Note that in neither of these cases we should let the signal pass unnoticed. Access violations and floating point exceptions may propagate through the program causing more harm than expected, and without process interrupts we will not be able to stop and cancel different threads. The only question that remains, though, is whether such signals can be handled by the thread in which they were generated and how.
......@@ -54,7 +54,7 @@ In addition to the set of synchronous signals or "exceptions", we have a set of
@itemize
@item Request for program termination (@code{SIGKILL}, @code{SIGTERM}).
@item Indication that a child process has finished.
@item Request for program interruption (@code{SIGINT}), typically as a consecuence of pressing a key combination, @kbd{Ctrl-C}.
@item Request for program interruption (@code{SIGINT}), typically as a consequence of pressing a key combination, @kbd{Ctrl-C}.
@end itemize
The important difference with synchronous signals is that we have no thread that causes the interrupt and thus there is no preferred way of handling them. Moreover, the operating system will typically dispatch these signals to an arbitrary thread, unless we set up mechanisms to prevent it. This can have nasty consequences if the incoming signal interrupt a system call, or leaves the interrupted thread in an inconsistent state.
......
......@@ -4,7 +4,7 @@
@clisp{} is a general purpose programming language. It lays its roots in
the @acronym{LISP} programming language @bibcite{LISP1.5} developed by
John McCarthy in the 80s. @clisp{} as we know it @ansi{} is the result
of an standarization process aimed at unifying the multiple lisp
of an standardization process aimed at unifying the multiple lisp
dialects that were born from that language.
@ecl{} is an implementation of the @clisp{} language. As such it derives
......
......@@ -23,7 +23,7 @@ suggested as an entry point for a new users who want to start using
@subsection Developer's guide
[@ref{Developer's guide}] documents @ecl{} implementation details. This
part isn not meant for normal users but rather for the ECL developers
part is not meant for normal users but rather for the ECL developers
and other people who want to contribute to @ecl{}. This section is prone
to change due to the dynamic nature of a software. Covered topics
include source code structure, contributing guide, internal
......
......@@ -4,7 +4,7 @@
The @ecl{} project is an implementation of the @clisp{} language that
aims to comply with the @ansi{} standard. The first ECL implementations
were developed by Giuseppe Attardi's who produced an interpreter and
compiler fully conformat with the Common-Lisp as reported in
compiler fully conformant with the Common-Lisp as reported in
@cite{Steele:84}. ECL derives itself mostly from Kyoto @clisp{}, an
implementation developed at the Research Institute for Mathematical
Sciences (RIMS), Kyoto University, with the cooperation of Nippon Data
......@@ -35,7 +35,7 @@ incorporated in @ecl{}.
The following is the partial list of contributors to ECL: Taiichi Yuasa
and Masami Hagiya (KCL), William F. Schelter (Dynamic loader,
conservative Gc), Giuseppe Attardi (Top-level, trace, stepper, compiler,
conservative GC), Giuseppe Attardi (Top-level, trace, stepper, compiler,
CLOS, multithread), Marcus Daniels (Linux port) Cornelis van der Laan
(FreeBSD port) David Rudloff (NeXT port) Dan Stanger, Don Cohen, and
Brian Spilsbury.
......
......@@ -14,15 +14,15 @@ featured a lisp to C translator.
@image{figures/kcl-hierarchy,,4.5in}
@end float
The KCL implementation remained a propietary project for some
The KCL implementation remained a proprietary project for some
time. During this time, William F. Schelter improved KCL in several
areas and developed Austin Kyoto Common-Lisp (AKCL). However, those
changes had to be distributed as patches over the propietary KCL
changes had to be distributed as patches over the proprietary KCL
implementation and it was not until much later that both KCL and AKCL
became freely available and gave rise to the GNU Common Lisp project,
GCL.
Around the 90's, Giusseppe Attardi worked on the KCL and AKCL code basis
Around the 90's, Giuseppe Attardi worked on the KCL and AKCL code basis
to produce an implementation of Common Lisp that could be embedded in
other C programs @bibcite{Attardi:95}. The result was an implementation
sometimes known as ECL and sometimes as ECoLisp, which achieved rather
......
......@@ -93,7 +93,7 @@ To and from element types
@end deftypefun
@subsubheading Description
@code{ecl_aet_to_symbol} returns the Lisp type associated to the elements of that specialized array class. @code{ecl_symbol_to_aet} does the converse, computing the C constant that is associated to a Lisp elment type.
@code{ecl_aet_to_symbol} returns the Lisp type associated to the elements of that specialized array class. @code{ecl_symbol_to_aet} does the converse, computing the C constant that is associated to a Lisp element type.
The functions may signal an error if any of the arguments is an invalid C or Lisp type.
......@@ -104,11 +104,11 @@ Creating array and vectors
@cppindex ecl_alloc_simple_vector
@cppindex si_make_vector
@cppindex si_make_array
@deftypefun cl_object ecl_alloc_simple_vector( cl_elttype element_type, cl_index length);
@deftypefun cl_object ecl_alloc_simple_vector (cl_elttype element_type, cl_index length);
@end deftypefun
@deftypefun cl_object si_make_vector( cl_object element_type, cl_object length, cl_object adjustablep, cl_object fill_pointerp, cl_object displaced_to, cl_object displacement);
@deftypefun cl_object si_make_vector (cl_object element_type, cl_object length, cl_object adjustablep, cl_object fill_pointerp, cl_object displaced_to, cl_object displacement);
@end deftypefun
@deftypefun cl_object si_make_array( cl_object element_type, cl_object dimensions, cl_object adjustablep, cl_object fill_pointerp, cl_object displaced_to, cl_object displacement);
@deftypefun cl_object si_make_array (cl_object element_type, cl_object dimensions, cl_object adjustablep, cl_object fill_pointerp, cl_object displaced_to, cl_object displacement);
@end deftypefun
@subsubheading Description
The function @code{ecl_alloc_simple_vector} is the simplest constructor, creating a simple vector (i.e. non-adjustable and without a fill pointer), of the given size, preallocating the memory for the array data. The first argument, @emph{element_type}, is a C constant that represents a valid array element type (See cl_elttype).
......@@ -117,9 +117,9 @@ The function @code{si_make_vector} does the same job but allows creating an arra
@itemize
@item element_type is now a Common Lisp type descriptor, which is a symbol or list denoting a valid element type
@item dimension is a non-negative fixnum with the vector size.
@item fill_pointerp is either Cnil or a non-negative fixnum denoting the fill pointer value.
@item displaced_to is either Cnil or a valid array to which the new array is displaced.
@item displacement is either Cnil or a non-negative value with the array displacement.
@item fill_pointerp is either ECL_NIL or a non-negative fixnum denoting the fill pointer value.
@item displaced_to is either ECL_NIL or a valid array to which the new array is displaced.
@item displacement is either ECL_NIL or a non-negative value with the array displacement.
@end itemize
Finally, the function @code{si_make_array} does a similar job to @code{si_make_function} but its second argument, @emph{dimension}, can be a list of dimensions, to create a multidimensional array.
......@@ -135,20 +135,20 @@ Create a one-dimensional @code{array} with a fill pointer
@verbatim
cl_object type = ecl_make_symbol("BYTE8","EXT");
cl_object a = si_make_vector(ecl_make_fixnum(16), type, Cnil, /* adjustable */
cl_object a = si_make_vector(ecl_make_fixnum(16), type, ECL_NIL, /* adjustable */
ecl_make_fixnum(0) /* fill-pointer */,
Cnil /* displaced_to */,
Cnil /* displacement */);
ECL_NIL /* displaced_to */,
ECL_NIL /* displacement */);
@end verbatim
An alternative formulation
@verbatim
cl_object type = ecl_make_symbol("BYTE8","EXT");
cl_object a = si_make_array(ecl_make_fixnum(16), type, Cnil, /* adjustable */
cl_object a = si_make_array(ecl_make_fixnum(16), type, ECL_NIL, /* adjustable */
ecl_make_fixnum(0) /* fill-pointer */,
Cnil /* displaced_to */,
Cnil /* displacement */);
ECL_NIL /* displaced_to */,
ECL_NIL /* displacement */);
@end verbatim
Create a 2-by-3 two-dimensional @code{array}, specialized for an integer type:
......@@ -156,10 +156,10 @@ Create a 2-by-3 two-dimensional @code{array}, specialized for an integer type:
@verbatim
cl_object dims = cl_list(2, ecl_make_fixnum(2), ecl_make_fixnum(3));
cl_object type = ecl_make_symbol("BYTE8","EXT");
cl_object a = si_make_array(dims, type, Cnil, /* adjustable */
Cnil /* fill-pointer */,
Cnil /* displaced_to */,
Cnil /* displacement */);
cl_object a = si_make_array(dims, type, ECL_NIL, /* adjustable */
ECL_NIL /* fill-pointer */,
ECL_NIL /* displaced_to */,
ECL_NIL /* displacement */);
@end verbatim
@subsubsection Accessors
......@@ -181,9 +181,9 @@ Reading and writing array elements
@end deftypefun
@subsubheading Description
@code{ecl_aref} accesses an array using the supplied @emph{row_major_index}, checking the array bounds and returning a Lisp object for the value at that position. ecl_aset does the converse, storing a Lisp value at the given @emph{row_major_index}.
@code{ecl_aref} accesses an array using the supplied @emph{row_major_index}, checking the array bounds and returning a Lisp object for the value at that position. @code{ecl_aset} does the converse, storing a Lisp value at the given @emph{row_major_index}.
The first argument to @code{ecl_aref} or @code{ecl_aset} is an array of any number of dimensions. For an array of rank @var{N} and dimensions @var{d1, d2 ...} up to @var{dN}, the row major index associated to the indices (@var{i1,i2,...iN}) is computed using the formula @code{i1+d1*(i2+d3*(i3+...))}.
The first argument to @code{ecl_aref} or @code{ecl_aset} is an array of any number of dimensions. For an array of rank @code{N} and dimensions @code{d1, d2 ...} up to @code{dN}, the row major index associated to the indices (@code{i1,i2,...iN}) is computed using the formula @code{i1+d1*(i2+d3*(i3+...))}.
@code{ecl_aref1} and @code{ecl_aset1} are specialized versions that only work with one-dimensional arrays or vectors. They verify that the first argument is indeed a vector.
......
......@@ -55,7 +55,7 @@ Note that @code{#\Linefeed} is synonymous with @code{#\Newline} and thus is a me
@node Characters - Newline characters
@subsection @code{#\Newline} characters
Internally, ECL represents the @code{#\Newline} character by a single code. However, when using external formats, ECL may parse character pairs as a single @code{#\Newline}, and viceversa, use multiple characters to represent a single @code{#\Newline}.
Internally, ECL represents the @code{#\Newline} character by a single code. However, when using external formats, ECL may parse character pairs as a single @code{#\Newline}, and vice versa, use multiple characters to represent a single @code{#\Newline}.
@c TODO: add an @xref to Stream -> External formats once it's written
......
......@@ -69,7 +69,7 @@ ECL_RESTART_CASE_BEGIN(the_env, cl_list(2, abort, use_value)) {
output = cl_eval(1, form);
} ECL_RESTART_CASE(1, args) {
/* This code is executed when the 1st restart (ABORT) is invoked */
output = Cnil;
output = ECL_NIL;
} ECL_RESTART_CASE(2, args) {
/* This code is executed when the 2nd restart (ABORT) is invoked */
output = ECL_CAR(args);
......
......@@ -21,11 +21,11 @@ error if such situation occur.
Moreover, while ANSI defines lambda list parameters in the terms of
@code{LET*}, when used in function context programmer can't provide an
initialization forms for required parameters. If required parameters
share the same name the error is signalled.
share the same name an error is signaled.
Described behavior is present in ECL since version 16.0.0. Previously
the @code{LET} operator were using first binding. Both @code{FLET} and
@code{LABELS} were signalling an error if C compiler was used and used
@code{LABELS} were signaling an error if C compiler was used and used
the last binding as a visible one when the byte compiler was used.
@node Minimal compilation
......@@ -149,7 +149,7 @@ ECL is implemented using either a C or a C++ compiler. This is not a limiting fa
@itemize
@item Functions that take a fixed number of arguments have a simple C signature, with all arguments being properly declared, as in @code{cl_object cl_not(cl_object arg1)}.
@item Functions with a variable number of arguments, such as those acception @code{&optional}, @code{&rest} or @code{&key} arguments, must take as first argument the number of remaining ones, as in @code{cl_object cl_list(cl_narg narg, ...)}. Here @var{narg} is the number of supplied arguments.
@item Functions with a variable number of arguments, such as those accepting @code{&optional}, @code{&rest} or @code{&key} arguments, must take as first argument the number of remaining ones, as in @code{cl_object cl_list(cl_narg narg, ...)}. Here @var{narg} is the number of supplied arguments.
@end itemize
The previous conventions set some burden on the C programmer that calls ECL, for she must know the type of function that is being called and supply the right number of arguments. This burden disappears for Common Lisp programmers, though.
......@@ -397,7 +397,7 @@ ECL_UNWIND_PROTECT_BEGIN(env) {
@end verbatim
@subsubheading Description
@code{ECL_UNWIND_PROTECT_BEGIN} establishes two blocks of C code that work like the equivalent ones in Common Lisp: a protected block, contained between the "BEGIN" and the "EXIT" statement, and the exit block, appearing immediately afterwards. The form guarantees that the exit block is always executed, even if the protected block attempts to exit via som nonlocal jump construct (@code{throw}, @code{return}, etc).
@code{ECL_UNWIND_PROTECT_BEGIN} establishes two blocks of C code that work like the equivalent ones in Common Lisp: a protected block, contained between the "BEGIN" and the "EXIT" statement, and the exit block, appearing immediately afterwards. The form guarantees that the exit block is always executed, even if the protected block attempts to exit via some nonlocal jump construct (@code{throw}, @code{return}, etc).
@var{env} must be the value of the current Common Lisp environment, obtained with @code{ecl_process_env}.
......
......@@ -19,7 +19,7 @@ Display the assembly code of a function
A symbol which is bound to a function in the global environment, or a lambda form
@end table
@subsubheading Description
As specified in ANSI @bibcite{ANSI} this function outputs the internal represention of a compiled function, or of a lambda form, as it would look after being compiled.
As specified in ANSI @bibcite{ANSI} this function outputs the internal representation of a compiled function, or of a lambda form, as it would look after being compiled.
ECL only has a particular difference: it has two different compilers, one based on bytecodes and one based on the C language. The output will thus depend on the arguments and on which compiler is active at the moment in which this function is run.
......@@ -48,7 +48,7 @@ List of symbols with traced functions.
@end table
@subsubheading Description
Causes one or more functions to be traced. Each @var{function-name} can be a symbol which is bound to a function, or a list containing that symbol plus additional options. If the function bound to that symbol is called, information about the argumetns and output of this function will be printed. Trace options will modify the amount of information and when it is printed.
Causes one or more functions to be traced. Each @var{function-name} can be a symbol which is bound to a function, or a list containing that symbol plus additional options. If the function bound to that symbol is called, information about the arguments and output of this function will be printed. Trace options will modify the amount of information and when it is printed.
Not that if the function is called from another function compiled in the same file, tracing might not be enabled. If this is the case, to enable tracing, recompile the caller with a @code{notinline} declaration for the called function.
......
......@@ -12,7 +12,7 @@
The @code{OPTIMIZE} declaration includes three concepts: @code{DEBUG},
@code{SPEED}, @code{SAFETY} and @code{SPACE}. Each of these declarations
can take one of the integer values 0, 1, 2 and 3. According to these
values, the implementation may decide how to compie or interpret a given
values, the implementation may decide how to compile or interpret a given
lisp form.
ECL currently does not use all these declarations, but some of them
......
......@@ -30,7 +30,7 @@ The way ECL parses a namestring is by first looking for the @var{hostname} compo
name = [.]wildcard-word
@end verbatim
If this syntax also fails, then the namestring is not a valid pathname string and a @code{parse-error} will be signalled.
If this syntax also fails, then the namestring is not a valid pathname string and a @code{parse-error} will be signaled.
It is important to remark that in ECL, all physical namestrings result into pathnames with a version equal to @code{:NEWEST}. Pathnames which are not logical and have any other version (i. e. @code{NIL} or a number), cannot be printed readably, but can produce a valid namestring which results of ignoring the version.
......
......@@ -35,7 +35,7 @@ In general, the size of a @code{FIXNUM} is determined by the word size of a mach
@node Numbers - Floating point exceptions
@subsection Floating point exceptions
ECL supports two ways of dealing with special floating point values, such as Not a Number (NaN), infinity or denormalized floats, which can occur in floating point computations. Either a condition is signaled or the value is silently used as it is. There are multiple options controlling which behaviour is selected: If ECL is built with the @code{--with-ieee-fp=no} configure option, then a condition is signaled for every inifinity or NaN encountered. If not, the behaviour can be controlled by @code{si:trap-fpe}. By default, a condition is signaled for invalid operation, division by zero and floating point overflows. If the @code{ECL_OPT_TRAP_SIGFPE} option is false, no conditions are signaled by default (Note that in this case, if you enable trapping of floating point exceptions with @code{si:trap-fpe}, then you have to install your own signal handler).
ECL supports two ways of dealing with special floating point values, such as Not a Number (NaN), infinity or denormalized floats, which can occur in floating point computations. Either a condition is signaled or the value is silently used as it is. There are multiple options controlling which behaviour is selected: If ECL is built with the @code{--with-ieee-fp=no} configure option, then a condition is signaled for every infinity or NaN encountered. If not, the behaviour can be controlled by @code{si:trap-fpe}. By default, a condition is signaled for invalid operation, division by zero and floating point overflows. If the @code{ECL_OPT_TRAP_SIGFPE} option is false, no conditions are signaled by default (Note that in this case, if you enable trapping of floating point exceptions with @code{si:trap-fpe}, then you have to install your own signal handler).
@lspindex si:trap-fpe
@defun si:trap-fpe condition flag
......@@ -197,7 +197,7 @@ Creating Lisp types from C numbers
@subsubheading Description
These functions create a Lisp object from the corresponding C number. If the number is an integer type, the result will always be an integer, which may be a bignum. If on the other hand the C number is a float, double or long double, the result will be a float.
There is some redundancy in the list of functions that convert from cl_fixnum and cl_index to lisp. On the one hand,@code{ ecl_make_fixnum()} always creates a fixnum, dropping bits if necessary. On the other hand, @code{ecl_make_integer} and @code{ecl_make_unsigned_integer} faithfully converts to a Lisp integer, which may a bignum.
There is some redundancy in the list of functions that convert from cl_fixnum and cl_index to lisp. On the one hand, @code{ecl_make_fixnum} always creates a fixnum, dropping bits if necessary. On the other hand, @code{ecl_make_integer} and @code{ecl_make_unsigned_integer} faithfully convert to a Lisp integer, which may be a bignum.
Note also that some of the constructors do not use C numbers. This is the case of @code{ecl_make_ratio} and @code{ecl_make_complex}, because they are composite Lisp types.
......
......@@ -18,7 +18,7 @@
@node Streams - Supported types
@subsubsection Supported types
ECL implements all stream types described in ANSI @bibcite{ANSI}. Additionally, when configured with option @code{--enable-clos-streams}, ECL includes a version of Gray streams where any object that implements the appropiate methods (@code{stream-input-p}, @code{stream-read-char}, etc) is a valid argument for the functions that expect streams, such as @code{read}, @code{print}, etc.
ECL implements all stream types described in ANSI @bibcite{ANSI}. Additionally, when configured with option @code{--enable-clos-streams}, ECL includes a version of Gray streams where any object that implements the appropriate methods (@code{stream-input-p}, @code{stream-read-char}, etc) is a valid argument for the functions that expect streams, such as @code{read}, @code{print}, etc.
@node Streams - Element types
@subsubsection Element types
......
......@@ -47,9 +47,9 @@ Building strings of C data
@subsubheading Description
These are different ways to create a base string, which is a string that holds a small subset of characters, the @code{base-char}, with codes ranging from 0 to 255.
@code{ecl_alloc_simple_base_string} creates an empty string with that much space for characters and a fixed lenght. The string does not have a fill pointer and cannot be resized, and the initial data is unspecified
@code{ecl_alloc_simple_base_string} creates an empty string with that much space for characters and a fixed length. The string does not have a fill pointer and cannot be resized, and the initial data is unspecified
@code{ecl_alloc_adjustable_base_string} is similar to the previous function, but creates an adjustable string with a fill pointer. This means that the lenght of the string can be changed and the string itself can be resized to accomodate more data.
@code{ecl_alloc_adjustable_base_string} is similar to the previous function, but creates an adjustable string with a fill pointer. This means that the length of the string can be changed and the string itself can be resized to accommodate more data.
The other constructors create strings but use some preexisting data. @code{ecl_make_simple_base_string} creates a string copying the data that the user supplies, and using freshly allocated memory. @code{ecl_make_constant_base_string} on the other hand, does not allocate memory, but simply uses the supplied pointer as buffer for the string. This last function should be used with care, ensuring that the supplied buffer is not deallocated.
......
......@@ -16,7 +16,7 @@ Many Lisp functions take keyword arguments. When invoking a function with keywor
@itemize
@item It is usually safe to store the resulting pointer, because keywords are always referenced by their package and will not be garbage collected (unless of course, you decide to delete it).
@item Remember that the case of the string is significant. @code{ecl_make_keyword("TO")} with return @code{:TO}, while @code{ecl_make_keyword("to")} returns a completely different keywod, @code{:|to|}. In short, you usually want to use uppercase.
@item Remember that the case of the string is significant. @code{ecl_make_keyword("TO")} with return @code{:TO}, while @code{ecl_make_keyword("to")} returns a completely different keyword, @code{:|to|}. In short, you usually want to use uppercase.
@end itemize
@subsubheading Example
......
......@@ -8,7 +8,7 @@ Operating systems on which ECL is reported to work: Linux, Darwin (Mac
OS X), Solaris, FreeBSD, NetBSD, OpenBSD, DragonFly BSD, Windows and
Android. On each of them ECL supports native threads.
In the past Juanjo José García-Ripoll maintained test farm which
In the past Juanjo José García-Ripoll maintained a test farm which
performed ECL tests for each release on number of platforms and
architectures. Due to lack of the resources we can't afford such doing,
however each release is tested by volunteers with an excellent package
......
......@@ -82,13 +82,13 @@ Create a protected region.
@end verbatim
@subsubheading Description
When embedding ECL it is normally advisable to set up an unwind-protect frame to avoid the embedded lisp code to perform arbitrary transfers of control. Furthermore, the unwind protect form will be used in at least in the following occasions:
When embedding ECL it is normally advisable to set up an @code{unwind-protect} frame to avoid the embedded lisp code to perform arbitrary transfers of control. Furthermore, the unwind protect form will be used in at least in the following occasions:
@itemize
@item In a normal program exit, caused by @code{ext:quit}, ECL unwinds up to the outermost frame, which may be an @code{CL_CATCH_ALL} or @code{CL_UNWIND_PROTECT} macro.
@end itemize
Besides this, normal mechanisms for exit, such as ext:quit, and uncaught exceptions, such as serious signals (@xref{Signals and Interrupts - Synchronous signals}), are best handled using unwind-protect blocks.
Besides this, normal mechanisms for exit, such as @code{ext:quit}, and uncaught exceptions, such as serious signals (@xref{Signals and Interrupts - Synchronous signals}), are best handled using @code{unwind-protect} blocks.
@subsubheading See also
@code{CL_CATCH_ALL}
......@@ -100,7 +100,7 @@ Besides this, normal mechanisms for exit, such as ext:quit, and uncaught excepti
@deftypefun int cl_boot (int @var{argc}, char **@var{argv});
Setup the lisp environment.
@table @var
@item argc,
@item argc
An integer with the number of arguments to this program.
@item argv
A vector of strings with the arguments to this program.
......@@ -177,7 +177,7 @@ This functions reads the value of different options that have to be customized @
@cppindex ecl_clear_interrupts
@defmac ecl_clear_interrupts();
@defmac ecl_clear_interrupts ()
Clear all pending signals and exceptions.
@subsubheading Description
......@@ -189,7 +189,7 @@ This macro clears all pending interrupts.
@cppindex ecl_disable_interrupts
@defmac ecl_disable_interrupts();
@defmac ecl_disable_interrupts ()
Postpone handling of signals and exceptions.
@subsubheading Description
......
......@@ -86,7 +86,7 @@ then nothing will be printed.
>
@end example
When an error is signalled, control will enter the break loop.
When an error is signaled, control will enter the break loop.
@example
> (defun foo (x) (bar x))
foo
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment