jyapayne/swig
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Disable Common Lisp / UFFI target language

Browse source 
Clean up to disable target languages that have been neglected/not functional.
Target language be fully deleted in SWIG 4.1 unless a new maintainer brings
it up to an acceptable status (experimental or supported).

Issue #1447
This commit is contained in:
William S Fulton 2019-02-04 20:01:05 +00:00
commit f63d0db21b
12 changed files with 12 additions and 119 deletions
Download patch file Download diff file Expand all files Collapse all files

48
TODO
View file

@ -275,54 +275,6 @@ Mzscheme
** Add shadow class support for the Swindle system.
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