Hi all,
I'm quite new to Scheme as such, though I have tinkered around with Gambit's ffi in the past. I am uncertain of the correct way of reusing code with Gambit. Possible options I have come across are slib, snow and black hole. What is the most preferred method of using other modules? If one of them has the functionality that I want, say, the zlib package in snow, and I have black-hole installed, what would be the best way around?
TIA. -aditya
Afficher les réponses par date
14 apr 2010 kl. 07.46 Aditya Godbole wrote:
I'm quite new to Scheme as such, though I have tinkered around with Gambit's ffi in the past. I am uncertain of the correct way of reusing code with Gambit. Possible options I have come across are slib, snow and black hole. What is the most preferred method of using other modules? If one of them has the functionality that I want, say, the zlib package in snow, and I have black-hole installed, what would be the best way around?
Hi,
This is a good question.
Being the author of Black Hole, I feel I should have something to say about this topic, but I'm afraid I don't have any conclusive advice. I can talk about some of the key characteristics of Black Hole though:
The goal of Black Hole is to be what you seek for, but it is not finished yet. It is becoming more and more mature, but it still has some important bugs and lacks a couple of important features.
I created Black Hole when me and Mikael Möre worked on a larger project in Gambit. Our code quickly became a mess, because we needed multiple entry points, macros that used libraries and so on. Using load and include, keeping track of double-loads, macros, macro-expansion time vs runtime just didn't scale. In the beginning it was a hack for that, which quickly grew into a more sophisticated tool.
At the moment, Black Hole is primarily a tool to help the internal organization of a library or application. It keeps track of module dependencies, macros and hygiene, and will soon keep track of run-time vs compile-time as well. It has some tools to do packages and package dependencies, but I haven't prioritized to work on them yet, because I have wanted to get the basic intra-project tools right first. This is a difference from Snow, which has a greater focus at interfacing between libraries than BH.
It's generally easy, but not no work, to port R5RS code to Black Hole. It basically involves changing loads and includes to Black Hole imports, to state dependencies between each file explicitly. So, if you want zlib from Snow and want to use Black Hole, you can just take the code from the zlib module in Snow, and change it to be a Black Hole module. IME this works fine if you only use a few external libraries.
Generally, Black Hole is not able to import things that are not Black Hole modules. Even though it's possible to hack around it, I wouldn't do it unless I wanted to import a very big library with only a few exported functions and no exported macros.
Black Hole is designed to be able to import Snow libraries. Writing a Snow library importer should not be very difficult to do, but it is not done.
Black Hole handles macros similarly to R6RS libraries. (But it doesn't have a syntax-case implementation at the moment.) A big difference between Black Hole and Snow is that Black Hole has support for hygienic macros.
I don't know very much about SLIB, so I can't say very much about how it compares to Black Hole.
Hope this helps,
Per