[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Chicken-users] Future of SWIG chicken module

From: John Lenz
Subject: [Chicken-users] Future of SWIG chicken module
Date: Mon, 26 Jan 2004 16:06:15 -0600

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

Useful links

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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]