Lazy pairs for Guile

The problem

Guile is an interpreter for the Scheme programming language, packaged as a library which can be incorporated into programs and can be used as a scripting language for the programs.

In my applications, I'd like to represent tree-like structures as the real Scheme lists to Guile. There are two issues here:

It's impossible to satisfy the both requirements. The problem is that list functions check the type of arguments, but we have to use a custom type for lazy instantiation of internal data as Scheme data.

So here is a type mismatch.


The solution is to patch the Guile source code.

When SCM_CAR or SCM_CDR sees a lazy value in a pair, it instantiates the value and updates the pair, replacing the lazy value by the instantiated value. So Guile always works with its native types, and all lazy work is hidden in the car/cdr.


General guidelines:

Use the function create_lazy_value to create a value of the type LazyValue. First argument is a callback and the second argument is a some pointer which is passed to callback without changes. This pointer is the only argument of the callback. The callback function returns a Guile SCM value.


The folder lazypair contains an example of representing C tree-like structures as Scheme lists. Usage:

High-level overview:

It worth to see the output from the printing the lazy tree twice:

( [node,type:pair]
#\A [node,type:pair]
( [node,type:pair]
#\B [node,type:char,value:C]
#\C ) [node,type:pair]
( [node,type:pair]
#\D [node,type:char,value:E]
#\E [node,type:char,value:F]
#\F ) ) 

( #\A ( #\B #\C ) ( #\D #\E #\F ) ) 

The text in square brackets is a logging output from the lazy callback. It is intermixed with the output from the tree priting function. The transcript demonstrates that Scheme list is growing on request and that internal Scheme functions (in this case pair? and for-each) work with a such list.

When printing the same tree the second time, the tree is already fully instantiated, and there are no lazy callbacks.


Files are hosted on SourceForge . Code is public domain (or maybe GPL as used as a part of the GPL product).

Comments are welcome.

Author: Oleg Paraschenko olpa@
Oleg A. Paraschenko <olpa uucode com>