2.4.1 Shadowed bindings

ANSI doesn’t specify what should happen if any of the let, flet and labels special operators contain many bindings sharing the same name. Because the behavior varies between the implementations and the programmer can’t rely on the spec ECL signals an error if such situation occur.

Moreover, while ANSI defines lambda list parameters in the terms of let*, when used in function context programmer can’t provide an initialization forms for required parameters. If required parameters share the same name an error is signaled.

Described behavior is present in ECL since version 16.0.0. Previously the let operator were using first binding. Both flet and 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.

2.4.2 Minimal compilation

Former versions of ECL, as well as many other lisps, used linked lists to represent code. Executing code thus meant traversing these lists and performing code transformations, such as macro expansion, every time that a statement was to be executed. The result was a slow and memory hungry interpreter.

Beginning with version 0.3, ECL was shipped with a bytecodes compiler and interpreter which circumvent the limitations of linked lists. When you enter code at the lisp prompt, or when you load a source file, ECL begins a process known as minimal compilation. Barely this process consists on parsing each form, macroexpanding it and translating it into an intermediate language made of bytecodes.

The bytecodes compiler is implemented in src/c/compiler.d. The main entry point is the lisp function si::make-lambda, which takes a name for the function and the body of the lambda lists, and produces a lisp object that can be invoked. For instance,

> (defvar fun (si::make-lambda 'f '((x) (1+ x))))
*FUN*
> (funcall fun 2)
3

ECL can only execute bytecodes. When a list is passed to eval it must be first compiled to bytecodes and, if the process succeeds, the resulting bytecodes are passed to the interpreter. Similarly, every time a function object is created, such as in defun or defmacro, the compiler processes the lambda form to produce a suitable bytecodes object.

The fact that ECL performs this eager compilation means that changes on a macro are not immediately seen in code which was already compiled. This has subtle implications. Take the following code:

> (defmacro f (a b) `(+ ,a ,b))
F
> (defun g (x y) (f x y))
G
> (g 1 2)
3
> (defmacro f (a b) `(- ,a ,b))
F
> (g 1 2)
3

The last statement always outputs 3 while in former implementations based on simple list traversal it would produce -1.

2.4.3 Function types

Functions in ECL can be of two types: they are either compiled to bytecodes or they have been compiled to machine code using a lisp to C translator and a C compiler. To the first category belong function loaded from lisp source files or entered at the toplevel. To the second category belong all functions in the ECL core environment and functions in files processed by compile or compile-file.

The output of (symbol-function fun) is one of the following:

• a function object denoting the definition of the function fun,
• a list of the form (macro . function-object) when fun denotes a macro,
• or simply 'special, when fun denotes a special form, such as block, if, etc.

ECL usually keeps the source code of a function unless the global variable si:*keep-definitions* was false when the function was translated into bytecodes. Therefore, if you don’t need to use compile and disassemble on defined functions, you should issue (setq si:*keep-definitions* nil) at the beginning of your session.

Variable: si:*keep-definitions* ¶

If set to t ECL will preserve the compiled function source code for disassembly and recompilation.

In Table 2.3 we list all Common Lisp values related to the limits of functions.

2.4.4 C Calling conventions

ECL is implemented using either a C or a C++ compiler. This is not a limiting factor, but imposes some constraints on how these languages are used to implement functions, multiple values, closures, etc. In particular, while C functions can be called with a variable number of arguments, there is no facility to check how many values were actually passed. This forces us to have two types of functions in ECL

• Functions that take a fixed number of arguments have a simple C signature, with all arguments being properly declared, as in cl_object cl_not(cl_object arg1).
• Functions with a variable number of arguments, such as those accepting &optional, &rest or &key arguments, must take as first argument the number of remaining ones, as in cl_object cl_list(cl_narg narg, ...). Here narg is the number of supplied arguments.

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.

As an example let us assume that the user wants to invoke two functions which are part of the ANSI [see ANSI] standard and thus are exported with a C name. The first example is cl_cos, which takes just one argument and has a signature cl_object cl_cos(cl_object).

#include <math.h>
...
cl_object angle = ecl_make_double_float(M_PI);
cl_object c = cl_cos(angle);
printf("\nThe cosine of PI is %g\n", ecl_double_float(c));

The second example also involves some Mathematics, but now we are going to use the C function corresponding to +. As described in ANSI dictionary, the C name for the plus operator is cl_P and has a signature cl_object cl_P(cl_narg narg,...). Our example now reads as follows

cl_object one = ecl_make_fixnum(1);
cl_object two = cl_P(2, one, one);
cl_object three = cl_P(3, one, one, one);
printf("\n1 + 1 is %d\n", ecl_fixnum(two));
printf("\n1 + 1 + 1 is %d\n", ecl_fixnum(three));

Note that most Common Lisp functions will not have a C name. In this case one must use the symbol that names them to actually call the functions, using cl_funcall or cl_apply. The previous examples may thus be rewritten as follows

/* Symbol + in package CL */
cl_object plus = ecl_make_symbol("+","CL");
cl_object one = ecl_make_fixnum(1);
cl_object two = cl_funcall(3, plus, one, one);
cl_object three = cl_funcall(4, plus, one, one, one);
printf("\n1 + 1 is %d\n", ecl_fixnum(two));
printf("\n1 + 1 + 1 is %d\n", ecl_fixnum(three));

Another restriction of C and C++ is that functions can only take a limited number of arguments. In order to cope with this problem, ECL uses an internal stack to pass any argument above a hardcoded limit, ECL_C_CALL_ARGUMENTS_LIMIT, which is as of this writing 63. The use of this stack is transparently handled by the Common Lisp functions, such as apply, funcall and their C equivalents, and also by a set of macros, cl_va_arg, which can be used for coding functions that take an arbitrary name of arguments.

2.4.5 C Reference

Function: void ecl_bds_bind (cl_env_ptr cl_env, cl_object var, cl_object value); ¶

Function: void ecl_bds_push (cl_env_ptr cl_env, cl_object var); ¶

Bind a special variable

Description

Establishes a variable binding for the symbol var in the Common Lisp environment env, assigning it value.

This macro or function is the equivalent of let* and let.

ecl_bds_push does a similar thing, but reuses the old value of the same variable. It is thus the equivalent of (let ((var var)) ...)

Every variable binding must undone when no longer needed. It is best practice to match each call to ecl_bds_bind by another call to ecl_bds_unwind1 in the same function.

Function: void ecl_bds_unwind1 (cl_env_ptr cl_env); ¶

Function: void ecl_bds_unwind_n (cl_env_ptr cl_env, int n); ¶

Undo one variable binding

Description

ecl_bds_unwind1 undoes the outermost variable binding, restoring the original value of the symbol in the process.

ecl_bds_unwind_n does the same, but for the n last variables.

Every variable binding must undone when no longer needed. It is best practice to match each call to ecl_bds_bind by another call to ecl_bds_unwind1 in the same function.

Function: cl_object ecl_setq (cl_env_ptr cl_env, cl_object var, cl_object value); ¶

C equivalent of setq

Description

Assigns value to the special variable denoted by the symbol var, in the Common Lisp environment cl_env.

This function implements a variable assignment, not a variable binding. It is thus the equivalent of setq.

Function: cl_object ecl_symbol_value (cl_object var); ¶

Description

Retrieves the value of the special variable or constant denoted by the symbol var, in the Common Lisp environment cl_env.

This function implements the equivalent of symbol-value and works both on special variables and constants.

If the symbol is not bound, an error is signaled.

Macro: typedef struct { ... } ecl_va_list[1]; ¶

Macro: ecl_va_start (ecl_va_list arglist, last_argument, narg, n_ordinary); ¶

Macro: cl_object ecl_va_arg (ecl_va_list arglist); ¶

Macro: cl_object ecl_va_end (ecl_va_list arglist); ¶

Accepting a variable number of arguments

Description

The macros above are used to code a function that accepts an arbitrary number of arguments. We will describe them in a practical example

cl_object my_plus(cl_narg narg, cl_object required1, ...)
{
    cl_env_ptr env = ecl_process_env();
    cl_object other_value;
    ecl_va_list varargs;
    ecl_va_start(varargs, required1, narg, 1);
    while (narg > 1) {
        cl_object other_value = ecl_va_arg(varargs);
        required1 = ecl_plus(required1, other_value);
    }
    ecl_va_end(varargs);
    ecl_return1(env, required1);
}

The first thing to do is to declare the variable that will hold the arguments. This is varargs in our example and it has the type ecl_va_list.

This arguments list is initialized with the ecl_va_start macro, based on the supplied number of arguments, narg, the number of required arguments which are passed as ordinary C arguments (1 in this case), the last such ordinary arguments, required, and the buffer for the argument list, varargs.

Once varargs has been initialized, we can retrieve these values one by one using ecl_va_arg. Note that the returned value always has the type cl_object, for it is always a Common Lisp object.

The last statement before returning the output of the function is ecl_va_end. This macro performs any required cleanup and should never be omitted.

Function: cl_object ecl_nvalues (cl_env_ptr env); ¶

Function: cl_object ecl_nth_value (cl_env_ptr env, int n); ¶

Accessing output values

Description

Common Lisp functions may return zero, one or more values. In ECL, the first two cases do not require any special manipulation, as the C function returns either nil or the first (zeroth) value directly. However, if one wishes to access additional values from a function, one needs to use these two macros or functions

• ecl_nvalues(env) returns the number of values that the function actually outputs. The single argument is the lisp environment. This value is larger or equal to 0 and smaller than ECL_MULTIPLE_VALUES_LIMIT.
• Once we know the number of return values, they can be directly accessed using the function ecl_nth_value(env,n), where n is a number larger than or equal to 1, and smaller than ECL_MULTIPLE_VALUES_LIMIT, which must correspond to a valid output value. No checking is done.

Note that in both cases these macros and functions have to be used right after the Lisp function was called. This is so because other Lisp functions might destroy the content of the return stack.

Example

A C/C++ excerpt:

cl_env_ptr env = ecl_process_env();
cl_object a = ecl_make_fixnum(13);
cl_object b = ecl_make_fixnum(6);
cl_object modulus = cl_floor(2, a, b);
cl_object remainder = ecl_nth_value(env, 1);

The somewhat equivalent Common Lisp code:

(multiple-value-bind (modulus equivalent)
    (floor 13 6))

Macro: ecl_return0 (cl_env_ptr cl_env); ¶

Macro: ecl_return1 (cl_env_ptr cl_env, cl_object value1); ¶

Macro: ecl_return2 (cl_env_ptr cl_env, cl_object value1, cl_object value2); ¶

Macro: ecl_return3 (cl_env_ptr cl_env, cl_object value1, cl_object value2, cl_object value3); ¶

Returning multiple values

Description

Returns N values from a C/C++ function in a way that a Common Lisp function can recognize and use them. The 0-th value is returned directly, while values 1 to N are stored in the Common Lisp environment cl_env. This macro has to be used from a function which returns an object of type cl_object.

Macro: ECL_BLOCK_BEGIN ¶

ECL_BLOCK_BEGIN(env,code) {

} ECL_BLOCK_END;

Description

ECL_BLOCK_BEGIN establishes a block named code that becomes visible for the Common Lisp code. This block can be used then as a target for cl_return.

env must be the value of the current Common Lisp environment, obtained with ecl_process_env.

The C/C++ program has to ensure that the code in ECL_BLOCK_END gets executed, avoiding a direct exit of the block via goto or a C/C++ return.

Macro: ECL_CATCH_BEGIN ¶

ECL_CATCH_BEGIN(env,tag) {

} ECL_CATCH_END;

Description

ECL_CATCH_BEGIN establishes a destination for throw with the code given by tag.

env must be the value of the current Common Lisp environment, obtained with ecl_process_env.

The C/C++ program has to ensure that the code in ECL_CATCH_END gets executed, avoiding a direct exit of the catch block via goto or a C/C++ return.

Macro: ECL_UNWIND_PROTECT_BEGIN ¶

C macro for unwind-protect

Synopsis

ECL_UNWIND_PROTECT_BEGIN(env) {

} ECL_UNWIND_PROTECT_EXIT {

} ECL_UNWIND_PROTECT_END;

Description

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 (throw, return, etc).

env must be the value of the current Common Lisp environment, obtained with ecl_process_env.

The utility of this construct is limited, for it only protects against nonlocal exits caused by Common Lisp constructs: it does not interfere with C goto, return or with C++ exceptions.

• ANSI Dictionary