diff options
author | Matthias Köppe <mkoeppe@mail.math.uni-magdeburg.de> | 2003-07-13 12:22:40 +0000 |
---|---|---|
committer | Matthias Köppe <mkoeppe@mail.math.uni-magdeburg.de> | 2003-07-13 12:22:40 +0000 |
commit | b9c9aba1705e15258c9fc12754bed9a1072339e0 (patch) | |
tree | 2b9a22437fbc596a9aac6a5008347abc9e589791 /TODO | |
parent | dcb94e7d4aa455cc97336e41d804654c60465529 (diff) | |
download | swig-b9c9aba1705e15258c9fc12754bed9a1072339e0.tar.gz |
Mark Guile garbage collection as done.
Add random thoughts on Common Lisp support.
git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk/SWIG@4960 626c5289-ae23-0410-ae9c-e8d60b6d4f22
Diffstat (limited to 'TODO')
-rw-r--r-- | TODO | 80 |
1 files changed, 51 insertions, 29 deletions
@@ -387,35 +387,7 @@ Guile ** Support GOOPS shadow classes. -** Support garbage collection. Here is a possible design: - - -- %new annotation decides whether a pointer smob can be gc'ed. - - -- New smob type `swig-gc'; instances created with - SWIG_Guile_MakeCollectablePtr. %new versions of the pointer - typemaps use this function rather than SWIG_Guile_MakePtr. - - -- New typemaps "destructor", "gcmarker". Their values are taken - as identifiers for functions taking one argument: a pointer to - the object to be destroyed, or whose SCM-valued subobjects are - to be marked. After creating the pointer equivalence table, - we iterate again over the remembered pointer types, emitting - code that puts the functions into our type table. No - additional functions are generated. - - -- The default for all pointer types would be: - %typemap(destructor) SWIGPOINTER * "free"; - (or "delete" for C++) - - -- A special annotation, e.g. FREED, can be attached to the - arguments of destructor functions, so that explicitly freed - structs won't be collected by the GC again. Like this: - - %typemap(argout) SWIGPOINTER *FREED { - smob-tag($source) = swig; /* non-gc */ - smob-data($source) = NULL; - } - void free_foo(struct foo *FREED); +[DONE] Support garbage collection. ** Make SWIG's types first-class by using a separate smob type for SWIG type descriptors; enable reflection on types. (Maybe @@ -429,6 +401,8 @@ Guile Mzscheme -------- +** Port list-vector.i and pointer-in-out.i from Guile. + Pike ---- @@ -441,6 +415,54 @@ Pike * Should investigate the possibility of generating .cmod files in addition to straight C/C++ code for extensions. +Common Lisp +----------- + +* Random thoughts by mkoeppe on supporting Common Lisp implementations: + + There are many different Foreign Function Interfaces (FFI) for + the various CL implementations. Probably SWIG should interface + to UFFI, a least-common-denominator FFI that supports many + implementations. + + Via the s-expression SWIG module we can export SWIG's parse + tree and import it into CL. It remains to check if all + relevant information is dumped (for instance, the type + information). Experimental code is available to generate + low-level UFFI declarations from this parse tree. + + However, for wrapping C++, we also need to create C wrappers + because most FFIs cannot directly import C++. A CL SWIG module + could be exporting both these wrappers and UFFI declarations. + I have experimental code (not checked in yet) that does this. + + This is fine for generating low-level wrappers. But how do we + support user typemaps (like converting lists and vectors to C + arrays on input)? We have to generate Lisp code that does the + conversion and then calls the low-level wrapper. If we + generate Lisp code, it should be beautiful and readable. + Therefore, we need at least a Lisp pretty printer. A Lisp + pretty printer works best when the Lisp program is represented + not as text but as Lisp data. Moreover, typemap writers will + feel very much constrained by SWIG's capabilities for + generating wrapper code, when compared to writing Lisp macros. + Thus we would need half a re-implementation of Lisp in SWIG to + make users happy. + + The solution could be the following: + +** Build a SWIG library (again) and load it into a Common Lisp + implementation. + + The FFI declarations could be written manually, or this could + be bootstrapped via the s-expression module or the primitive + UFFI wrappers. This should be easy because SWIG's API is quite + simple. + + The embedded SWIG would be driven by a CL program. High-level + typemaps would be written as Lisp programs that generate Lisp + code. + Documentation ------------- |