Representation of in-memory structures as Scheme lists is not transparents. Problems are demonstrated using the Scheme implementation Guile.
Guile tracks data types by tags. "eq*?"-predicates check for tags first and return #f if tags are not the same.
For example, "(doc)" from binding and the real "(doc)" are not "equal?". So we should use the function "nodeset-equal?" to compare nodesets. TODO: redefine also 'node-eq?' and 'node-equal?' in SXPath.scm.
Second problem are the strings. We can't return them as real strings because we have to store a pointer to the origin of the string. SXML applications should be aware that "string-equal?" doesn't work. They should use "text-node?" first, then "node-value", and only then "string-equal?".
Indeed, it's not a problem to redefine all list functions. But I expect problems with "apply" and with internals.
(
link)
Hello,
I'm making a binding to a C program. One of the memory structures in the program is a list which can contain sublists and strings. I'd like to present this structure as the Scheme list in Guile, so the usual list functions like 'car', 'cdr', 'for-each' etc would work.
A trivial approach is to write a function (let name it "memory->list") which creates a real Scheme list from the data. But I wonder if it is possible to complicate things.
First, the data in memory are big enough, and full instantiation of lists wastes resources, especially because I use only small part of the data. Instead, I'd like to have lazy instantiation. Let "memory->list" returns a special type of pair in which car and cdr are instantiated on demand. Is it possible?
The second. Having Scheme data, I'd like to get the origin of this data in the C program. Currently I think about mapping from SCMs to C structures in C-Guile glue, but I'm afraid this is bad for garbage collection.
I'd be thankful for your comments and suggestions.
Regards, Oleg
On example of xsltproc (an XSLT processor) and Guile (a Scheme implementation).
On the former. Scheme functions like "car", "map" etc should work correctly on lazy trees. Unfortunately, Guile doesn't support implicit creation of values for these functions. To overcome the problem, a patch for Guile is created: Lazy pairs for Guile.
On the mapping. Mapping pairs are added during conversion from XML to Scheme. It is found that there is no reason to establish mapping during conversion from Scheme to XML: libxslt makes a copy of tree anyway.
The important persistency property: if two XML nodes are physically the same nodes, the corresponding Scheme values are also phusically the same. There are some complications for attribute and namespace nodes. The explanation is TODO for the XSieve documentation.