This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
hi all i've written a Guile plug-in for Gnumeric (the GNOME spreadsheet). i'd like to invite you to check out the CVS version of Gnumeric and take a look at it. since i'm pretty new to Guile, i'd really appreciate if you could browse through the code (plugins/guile) and tell me what i did wrong :-). one of the highlights of the plug-in is that it is able to operate not only on the values residing in the cells but also on the expressions. as examples of what is possible i have written a little expression simplifier (constant folding and simplification of things like x*1, a+0) and a symbolic differentiator. they are not neatly integrated with Gnumeric yet, however. the plug-in exports two functions to Gnumeric: scm_eval and scm_apply. both do pretty much the obious. e.g.: =scm_eval("(+ 1 1)") =scm_apply("(lambda (a b) (if (> a b) a b))",1,2) one can of course write new Gnumeric functions in Scheme. examples can be found in plugins/guile/gnumeric_startup.scm. my main concern is currently (apart from the trivial tasks) a smob wrapper for Gnumeric's ExprTrees (ExprTree is the data structure Gnumeric uses for internally storing expressions). the problems are: * ExprTrees are reference counted. Can be solved by increasing the refcount if an ExprTree is smobified. In order to avoid increasing the refcount more than once, a list of all smobified ExprTrees would need to be kept. * ExprTrees are recursive. This means that if the user traverses the whole ExprTree from out of Guile, a smob for every node would need to be created. Is this ok? * CellRefs can be (and usually are) relative. This means that in order to evaluate an ExprTree its cell must be known in order to resolve the relative CellRefs. Thus, most functions dealing with ExprTrees would need to be passed the original CellRef. Another possibility would be to store the CellRef in the smob. Yet another solution would be to have a 'current CellRef' variable. Somehow, none of these solutions appeal to me. Suggestions, anyone? i hoped maybe someone could give me some advice on these topics. bye schani -- Mark Probst Student, Programmer http://www.unix.cslab.tuwien.ac.at/~schani/