diff options
Diffstat (limited to 'TODO')
| -rw-r--r-- | TODO | 68 |
1 files changed, 0 insertions, 68 deletions
@@ -275,74 +275,6 @@ Mzscheme ** Add shadow class support for the Swindle system. -Pike ----- - -* Decide how to handle global variables (probably using something - like the Python module's cvar). Affects Examples/pike/simple. - -* Decide how to handle static class member functions and member - variables. - -* 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. - -ALLEGROCL ------ -These first three will remove most of the warnings from most of the -remaining checkpartial tests that are failing. -**** Throws typemap support -**** const typemaps -**** long long typemaps - Ocaml ----- ** I've been working with my camlp4 module and type information |