Hi, > > This looks promising. Thanks for starting it off > and being so enthusiastic. >
It does sound like a fun thing, and I think this will be very little work for me. > Taking a look at the APIs for Perl, Python, R, Tcl, Java, etc. > would also be good. One thing that all of these provide is > a specific typedef for an object. I imagine Yacas does also, > so rather than returning void *, it would be nicer to > return that type. > Good point to have type safety. But Yacas uses classes. A number will actually be a different object from a string, but derived from the same base class. The void* would simply mean a pointer to something derived from the base class. We can perhaps typedef a YacasObject, to be a pointer to void. Would that already provide enough safety? The other option indeed is to allow full access to the internals. For this I would probably need to expose the entire set of header files, not just the file cyacas.h. To me it feels more elegant to expose just what one wants to expose, hence the clear API definition. We can export certain methods of certain classes, so you could actually just call LispAtom::New or LispSubList::New, literally the classes that are already available. The disadvantage with exposing the full internals is that I would basically be promising that the internals will never change in the future. The API abstracts away the internals. There are discussions currently going on on changing the representation of the trees internally, to experiment with different algorithms. It is a matter of design. I am ok with exposing all the internals, but I would rather not promise that I will not overhaul the internals. Ayal ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
