[Ecls-list] Any documentation for the C library?

[Gabriel Dos Reis]

On Mon, Feb 23, 2009 at 4:31 AM, Juan Jose Garcia-Ripoll
<juanjose.garciaripoll at googlemail.com> wrote:
> On Mon, Feb 23, 2009 at 11:18 AM, Gabriel Dos Reis
> <gdr at integrable-solutions.net> wrote:
>>  I suspect a derivative question is to what extent people having to
>> write FFI functions using low-level utils can depend on the
>> stability of data structures defined in object.h.  For example, the
>> recent addition of Unicode support has the effect of chaning
>> ecl_array_datat members -- the 'ch' was gone -- therefore
>> breaking some FFI codes that depended on that.
>
> Let's say that ECL's interface is not mature enough to fix the
> internal structure and data types of all objects. You get every day
> messages with further optimizations regarding different parts
> (Unicode, C functions, etc) that would not be possible if I froze
> those structures.

That is understood.

>
> I would recommend staying with the high level functions and macros and
> _not_ inspecting object's structure or use types that seem internal
> enough. ECL has plenty of functions to do that. ecl_length() for array
> sizes, ecl_aref(), ecl_aset(), ecl_copy_subarray(),
> ecl_reverse_subarray(), etc, These functions help you avoid using any
> kind of pointers.

A typical situation for OpenAxiom is how to properly write an FFI for
a foreign function that takes a pointer to the first element of an array
of double or array of int.  And how to call it.  These are automatically
generated signatures and calls.  At the moment, OpenAxiom for
ECL generates c-inline calls by refering to fields of ->vector.self
of an object.

>
> However, I can not predict everybody's needs. My recommendation then
> is that if you access some critical field of a lisp structure, you
> wrap that accessor in a macro that can be later on redefined. If that
> macro is frequently used it might even make sense to add it to the
> core library -- for instance, retrieving the pointer from an array.

The problem for OpenAxiom is when there are several ECL versions out
there with differing structures and having to support each of them.  For example
I develop with current trunk, but some OS distros chip either 0.9l or
8.12.0.

>
> Indeed at some point it will make sense to sit down and make a list of
> all reader and setter functions or macros that remain to be written
> and add them to the object.h and external.h headers.

-- Gaby