I forgot one API call, getting a potential error caused through evaluating the object. And I forgot one argument needed for evaluating, the pointer to the environment. Ayal
On Jul 17, 2005, at 5:29 PM, Ayal Pinkus wrote: > > Hi, > > >> >> The thing that I wonder is whether it would be possible to embed >> Yacas >> at a lower level than via the parser. E.g. the Tcl embedding has >> Tcl_EvalObjEx() and friends, which operate on preparsed Tcl objects. >> Using this instead of Tcl_Eval() gives some efficiency gain, but more >> importantly, it avoids the "quoting hell" associated with the >> construction of the relevant command strings. >> >> > > Interesting. You are not the first person asking this, actually. > > I chose for the C API as it is nice and clean, no name mangling issues > while switching to a new gcc compiler, and it allows people to use it > from C also. Back then, I thought all people would want to do is > send a > string and receive one back. > > > >> Since both R and Yacas are "Lisp under the hood" languages (and Tcl >> too for that matter), it is a fairly good guess that their parse >> trees >> are similar, and that it would be a fairly simple task to translate >> back and forth between them. Well, between suitable subsets, at >> least. >> R's parse trees can in principle contain arbitrary R objects, but in >> this context, we might only need constants, names, operators, and >> function calls. >> >> > > > Very true. The code to chain up the linked list itself would not be > very > little code, but we could iron out an initial API of course. It could > even > be through a C interface that returns void*. > > Yacas can Already read a Lisp-style representation, to wit: > > In> FromString("(foo(List a b))")LispRead() > Out> foo({a,b}) > > but that would not help you much as you mention you'd like to avoid > quoting hell. > > From a C perspective, an API could look like this: > > // Creating objects > void* yacas_create_atom(char* atom); > void* yacas_create_string(char* string); > void* yacas_create_number_from_string(char* string); > void* yacas_create_number_from_long(long number); > void* yacas_create_number_from_double(double number); > void* yacas_create_sublist(void* object); > > // Linking linked lists > void yacas_link_objects(void* head, void* tail); > > // executing an object > void* yacas_execute(void* object); > > // pulling apart an object again > void* yacas_get_sublist(void* object); > char* yacas_get_atom(void* object); > char* yacas_get_string(void* object); > int yacas_object_is_string(void* object); > int yacas_object_is_atom(void* object); > int yacas_object_is_number(void* object); > int yacas_object_is_integer(void* object); > long yacas_get_long(void* object); > long yacas_get_double(void* object); > > Note in the above list you would only really need get_sublist and > get_atom, > but using the others might be more efficient. > > > >> It is probably not quite as easy as it sounds (is it ever?) but it >> could be worth it anyway. The main thing that it would require is an >> extended Yacas API which allows you to create Yacas objects from C >> code. >> >> > > > Apart from the above API, which I could create and would not take too > long, > there is of course the task of converting, in the sense that the > semantics > of R trees will be different from the semantics of the Yacas tree. > > The other alternative is OpenMath, but that is just too verbose. I > don't like > xml-like schemes myself, as it is a very inefficient way of doing > this. > > Do you have cvs, and the possibility to compile under Windows? > Ayal > > > > [[alternative HTML version deleted]] > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel