[Ecls-list] Normalizing the API

[Juan Jose Garcia-Ripoll]

In parallel with preparing the next release, I am working on a separate code
branch that tries to finish the task of fixing ECL's C API.

There are several things to do but the most important ones are

- Remove useless macros
- Provide accessors for all object properties that are there to stay
- Prefix macros and functions with ECL_, CL_, SI_ or EXT_
- Thinking again about function names and providing compatibility macros for
deprecated ones.

I have been also thinking about the names and spelling of macros and
functions. So far most of the C macros are uppercase names and may
interrogate the macro argument twice, as in

#define ECL_ARRAYP(x) ((_ecl_tag(x) == 0) && (x)->d.t >= t_array && (x)->d.t
<= t_bitvector)

The main problem is the lack of uniformity:

- Some macros check their arguments, most do not
- Some macros do have lowercase names, but typically they do not evaluate
their argument twice
- Some functions prefixed with ecl_ do not check their arguments, others do.

If we had inline functions as standard things might be easier, but we would
still have to decide to do argument checking, not to do it, providing
versions of both or deciding a feature in the name that makes it easy to
test it.

So far I am more or less approaching the following rules

- Accessors for object elements, as in ECL_SINGLE_FLOAT_VALUE are uppercase.
- Macros are all uppercase if we can not guarantee that they evaluate their
argument once.
- Names are being changed to make them more like Common Lisp (sf(x) ->
ECL_SINGLE_FLOAT_VALUE(x)), etc.
- All type predicates (ECL_ARRAYP) are uppercased macros.
- I am also inclined towards removing type checks from ecl_* functions
except when the check is extremely cheap, as when we have performed a
dispatch based on type.

Help is welcome for improving the overal design

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://tream.dreamhosters.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20100327/07b34491/attachment.html>