I don't have the time to dig into your code. Just to make sure:
- be sure to compile the program; the Gambit interpreter does not analyze the lifetime of lexical bindings, and thus retains memory longer than necessary, and thus possibly longer than you anticipated. So make sure you compile the program before concluding that it has a memory problem.
- if there is in fact a memory problem with the compiled program, then run it in the interpreter ;-). Or at least partially (you could compile the parts of the programs you don't want to analyze at the moment). Because then you can easily step through it and find out what happens. (For debugging, also make sure you know how to use |generate-proper-tail-calls|.)
- find out what the reason of the out of memory situation could be: is (a) your problem maybe just asking for more memory than you've got?, or (a2) your problem doesn't necessarily ask for more memory than you've got in principle, but the way you're evaluating it (e.g. calculate to eagerly) requires too much memory at once, or (b) you've got an error in the program which leads to an infinite loop allocating memory, or (c) your program is holding on to memory that it doesn't need anymore?
For (c) check your assumptions about the lifetime of memory: particularly, be aware that structs (as defined using define-structure or define-type), or in fact any data structure like cons cells and vectors, will hold on to every location in them, even to those you'll never use again (this is unlike lexical bindings, which, as I've told above, will be analyzed by the compiler and only live as long as the program will possibly refer to them). If in doubt, copy the relevant data to new datastructures (or, if you want to go imperative, delete places in the structure by setting them to #f or (void) or whatever).
For (a2) using delay and force can help; but check my post at https://webmail.iro.umontreal.ca/pipermail/gambit-list/2007-May/001435.html, i.e. the current promises actually do retain memory longer than they have to ;), this is an example for which my hint above for problem (c) applies. So you might actually want to use the implementation of delay and force given in that mail.
Note that when heeding these precautions I could never get Gambit to leak memory in compiled programs. (So my expectation is that (unless some other implementation implement structures or vectors as dissectable entities, which I doubt) you won't get better behaviour by porting to other implementations.)
Christian.