%eclent; ]>

&ANSI; doesn't specify what should happen if any of the LET, FLET and LABELS blocks contain many bindings (or functions) 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 occurs. This is also very unlikely, that programmer does that intentionally, since there is no valid use-case for it. 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 error is signalled. Described behavior is present in &ECL; since version 16.0.0. Previously the LET operator were using first binding, while lambda lists used last occurrence. Both FLET and LABELS were singalling an error if C compiler was used and used last binding as visible one when bytecmp was used.

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.

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 drops the source code of a function unless the global variable si:*keep-definitions* was true when the function was translated into bytecodes. Therefore, if you wish to use compile and disassemble on defined functions, you should issue (setq si:*keep-definitions* t) at the beginning of your session. In we list all &CommonLisp; values related to the limits of functions. call-arguments-limit 65536 lambda-parameters-limit call-arguments-limit multiple-values-limit 64 lambda-list-keywords (&optional; &rest; &key; &allow-other-keys; &aux; &whole; &environment; &body;)

&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 acception &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; 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 the C 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.