[Chicken-users] Future of SWIG chicken module

[John Lenz]

I am sending this email to raise the issue of the status and future of  
the SWIG chicken module.

Useful links
http://www.swig.org
http://www.call-with-current-continuation.org/chicken.html

The current chicken SWIG module is useable but broken (it has a major  
bug with the runtime code). The original submitter and maintainer of  
the SWIG chicken module, Jonah Beckford, seems to have dissappeared and  
currently I believe the SWIG chicken module is unmaintained.

The major problem with the chicken SWIG module is the incorrect usage  
of the swig runtime code, see the SWIG bug #782468
http://sourceforge.net/tracker/?func=detail&aid=782468&group_id=1645&atid=101645

I do not know a lot about chicken internals, but it seems to me that  
chicken now has some automatic C++ wrapping implemented.  Since the  
maintainer of the SWIG chicken module is not around anymore and the  
SWIG chicken module has some serious bugs in it, my question is

Is it worth fixing and maintaing the SWIG chicken module?

SWIG has advantages over the C++ parser and wrapper in chicken
- Almost complete C/C++ parser. (SWIG can take and wrap pretty much any  
header file)
- Operator overloading
- Exceptions
- Member variables
- template support? (SWIG has template support... does chicken?)
- variable argument functions (SWIG supports these, does chicken?)
- customized type conversion (typemaps)

SWIG features that chicken does not use but features which the SWIG  
chicken module could be expanded to use.
- directors
- c++ typemaps (std::vector<>, std::map<>, etc...)

In my opinion, chicken seems to be growing to include many of the  
features of SWIG and duplicate effort should be eliminated.  I think  
effort should be focused on using and developing either SWIG or the  
chicken parser and wrapper, but not both.

1) Plan on using the current chicken c/c++ parser and wrapper and just  
get rid of the SWIG chicken module.  With this route, SWIG and chicken  
would part ways and the chicken c/c++ parser and wrapper could be  
expaneded to include the features that were needed (if any).  The SWIG  
chicken module would then be depreciated and unmaintained, and if any  
changes to SWIG in the future cause the chicken module to break  
completly, the chicken module would then just be removed.  The decision  
then would be up to David Beazley, the SWIG maintainer, when to remove  
the module (maybe just remove the chicken module now).

2) Maintain the SWIG chicken module.
I would be willing to maintain the SWIG chicken module if there is  
enough interest in it.  If we go this route, a lot of technical  
decisions need to be made about how the module will work.  The c++  
parser and wrapper in chicken could be removed and chicken could call  
SWIG to parse c and c++ stuff.  This would be an interesting approach,  
because then using SWIG would be completly transparent.  Chicken would  
pass to SWIG the C or C++ definitions and SWIG would then return the  
scheme definitions.  For example, SWIG would be given the C string "int  
add(int a, int b)" and would return say "(define add (foreign-lambda  
int "add" int int))" which would then be further processed by chicken.   
With this approach, chichen would almost immediatly get all the  
features of SWIG!

Again the decision that should be made now is that since chicken and  
SWIG overlap in a lot of what they do, does SWIG bring enough new  
features and does SWIG provide a useful tool for writing chicken code?   
Is there enough interest and is it worth the effort to update and  
maintain the SWIG chicken module?

And then if it is worth maintaining the SWIG chicken module, there are  
a bunch of technical decisions to be made on exactly how SWIG and  
chicken will interact, which I will discuss in more detail if we choose  
this option.

John