[Ecls-list] Any documentation for the C library?
Juan Jose Garcia-Ripoll
juanjose.garciaripoll at googlemail.com
Mon Feb 23 10:31:36 UTC 2009
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.
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.
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.
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.
Juanjo
--
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28009 (Spain)
http://juanjose.garciaripoll.googlepages.com
More information about the ecl-devel
mailing list