diff options
author | Haibo Huang <hhb@google.com> | 2019-10-08 15:48:26 -0700 |
---|---|---|
committer | Haibo Huang <hhb@google.com> | 2019-11-14 22:14:23 +0000 |
commit | 80b4251e302efb18c145a4786249d695397ed42a (patch) | |
tree | 12b9dec2513f7caa92e7835bc17ab16ae5635df6 /TODO | |
parent | 189852d8cdfd5863c52ec7aa73affd926c5a3f43 (diff) | |
parent | 1e36f51346d95f8b9848e682c2eb986e9cb9b4f4 (diff) | |
download | swig-80b4251e302efb18c145a4786249d695397ed42a.tar.gz |
Upgrade swig to 'rel-4.0.1'llvm-r383902b
Also run autogen.sh to generate configure files.
Exempt-From-Owner-Approval: add myself to owners
Change-Id: I391aa20428836ae74dab8c8427627ca4dbc8ecf4
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 |