[Ecls-list] Extending compiler representation types

Steve Smith tarka at internode.on.net
Sat Oct 20 04:54:05 UTC 2007


One thing that would be useful is to allow packages to extend the
compiler type representations.  

For instance, as you may know I'm currently adding some low-level unix
functionality via the FFI. Currently I have to approximate the
representation of opaque types either by allocating a memory area of
the same size or using the closest type match (:long for pid_t).  A
more elegant solution may be to allow this to represented directly as
they are in the '+representation-types+' list in cmpffi.lsp.  For
example, I'd like to be able to do something like this:

  (clines "#include <sys/types.h>")
  (ffi:add-representation '(:pid ((integer #.si:c-long-min #.si:c-long-max) "pid_t")))

>From then on :pid could be used as a representation type for c-inline.

Another useful (but probably trickier) functionality would be mapping
opaque types:

  (clines "#include <sys/select.h>")
  (ffi:add-representation `(:fdset (,(memblock "fd_set") "fd_set")))

'memblock' would be a macro that retrieves the size of fd_set with
size_of() and allocates an array of unsigned char as the lisp
representation of that opaque type.  In practice it may even be better
to represent all c-types with the memblock representation as this is
more portable.

Does this seem worthwhile?  Does it even make sense?  I'm happy to be
involved in adding it, but I wouldn't know where to start currently.


More information about the ecl-devel mailing list