The other night I was daydreaming about buying a Chez Scheme license so I checked up on their license costs.
They are now Apache Licensed OSS.
Funny timing as they opened up only days prior.
The issue board is already active.
#chez on Freenode is blessed though the channel doesn’t seem to be up yet.
This is all delightful.
Thanks to the efforts of the SRFI authors, the R6RS SRFI library team, and Aaron, Chez has the portable R6RS SRFI libraries up and running on it.
A single R6RS code-base used among all of the different R6RS implementations means substantial code-reuse, and all of the benefits that it brings.
(via comp.lang.scheme)
A R6RS conformant Chez Scheme 7.4D and TSPL4 now available.
Surprised?! I was. I hadn’t heard anything either. Anywhere. From anyone.
Yesterday though, I saw Aaron (dedicated Chez user) posting about R6RS ports here and Eduardo mentioned TSPL4’s availability here here.
Addendum: 08/04/09
The TSPL4 link is broken, but was not at the time of posting. Since the hardcopy hasn’t been released yet, I suspect that the link will be down until the hard copy is released.
Addendum: 08/08/09
The link is back up.
FWIW: I didn’t think it was worth bothering Kent by asking about why it was down in the first place.
An R6RS library and a Chez top-level module have similarities: they both have bodies that contain variable and syntax definitions, some of which can be exported, and you can import one module into another. So, they’re similar on the surface. But there are major differences.
1. Outer scope
Chez modules exist in some environment (typically, in the interaction-environment, but that can change) that contains bindings that include the module keyword itself. The outer scope in the environment in which the module is expanded is visible inside the module (unless you restrict it using the import-only keyword). R6RS/Ikarus libraries do not exist in an environment: they are stand-alone entities with their own syntax and so on.
2. Expansion and Evaluation
Ikarus libraries are automatically expanded/compiled when you import them (thus, there’s a mapping from library names to some storage that contains libraries’ code). Chez modules are not associated with any storage: if you import a module and it doesn’t already exist in the environment, you get an error. This means that in Chez, it is your duty to ensure that modules are “loaded” before they are used. Now “loaded” is a loaded term as it implies all of “compiled”, “visited”, and “invoked” (or “revisited” in the Chez lingua). Moreover, the load, compile, visit, and revisit are operations that operate on files, not modules, (such files may contain any code, not just modules) and work by modifying the environment in which such files are loaded, compiled, visited, or revisted. Operations on libraries in Ikarus do not modify the environment since no environment is required for performing these operations. In short, you need to manage the phase dependencies (when files are loaded/compiled/visited/revisited) yourself so that compile-time and run-time information are available when needed.
Aziz,,,
(via Ikarus)
