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] |
On Thu, Nov 12, 1998 at 09:29:48AM -0500, Russ McManus wrote: > When I worked on a scheme spreadsheet I called these the raw and > cooked values, respectively. It sounds like you want to make each > cell visible from scheme, where the cell gives the programmer access > to the raw and cooked values. correct. > When you have a C data structure whose lifetime is determined in C, > (Xt Widgets are a good example), there are strategies you can use. I > have adapted some code I have to your example: first, i doubt that miguel will allow me to extend the Cell type in order to contain a reference to the scheme object, which i don't want to do anyway, so i will have to make that association externally, which is not a problem, however. second, are you sure the following function is ok? > static scm_sizet > cell_sweep(SCM obj) > { > cell->obj_init_p = 0; > cell->obj = SCM_UNDEFINED; > cell_decrease_refcount(cell); /* this will only happen when the scheme */ > /* object's lifetime ends */ > } > My code above shows how to keep the consing to a minimum for this. > Only when a particular cell is exported to scheme is the cost of > preparing a scheme representation incurred. If the same cell is > exported to scheme twice, the scheme representation is reused. that's what i though of, too. sounds pretty reasonable. > > * 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? > > Does my code above provide a potential solution? I think it does, > unless I don't quite understand your question. the latter is the case :-). the problem is that it is possible to refer to cells by absolute and by relative position. the latter makes it necessary to have some refernence point (the current cell). i don't want to introduce the notion of a current cell, though, neither do i want to pass around a CellRef through all functions just in case somebody wants to eval a relative CellRef. bye schani -- Mark Probst Student, Programmer http://www.unix.cslab.tuwien.ac.at/~schani/