Differences between the Chez and Ikarus module systems

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)

What you do

We no longer care what you say.
We care a great deal about what you do.
If you charge for hand raking but use a leaf blower when the client isn’t home
If you sneak into an exercise class because you were on the wait list and it isn’t fair cause you never get a bike
If you snicker behind the boss’s back
If you don’t pay attention in meetings
If you argue with a customer instead of delighting them
If you copy work and pass it off as your own
If you shade the truth a little
If you lobby to preserve the unsustainable status quo
If you network to get, not to give
If you do as little as you can get away with
…then we already know who you are.

(via Seth)

Decentralized Scheme Code Tracker

Aaron posted here here about Descot; a scheme to manage Scheme libraries. This is the alpha version. Based on his explanation, my impression is that the goal is to simplify the management and distribution of libraries without being a package manager itself like PLT and Chicken Scheme include. Those managers, though, might use Descot as a source of libraries.

Why there is not restart exception handling in PLT Scheme

YC asked here[1]:

Is it possible to handle exceptions like Common Lisp, specifically restarts?
Scenario: undefined variables – handling by defining the variable, and continue past the exception.

Matthew explained what is and is not possible in the following threads here, here, and here.
[1]: PLT Scheme Mailing list, “restart exception handling?”, Thu Jul 10 17:35:57 EDT 2008

Two sids of the same coin: coroutines and streams

Jos asked here:

It seems to me that in many cases the same problem can be solved (for an eager evaluater) both by coroutines and by streams. Both solutions very well show the structure of the principal algorithm as might have been written with a lazy evaluator in mind. Which approach would be preferred in terms of efficiency (time and memory). May be you would like to address other aspects as well. One reason that makes me tend to choose streams, is that the latter seem better suited to automatic code generation from purely lazy code.

To which Matthais replied here:

It is indeed a well-known fact that streams and coroutines are two sides of the same coin. Talcott’s 1986 dissertation is the earliest theoretical treatment that I know.

Which Jim clarified here:

I believe the reference is to Carolyn Talcott’s dissertation “The essence of Rum: A theory of intensional and extensional aspects of Lisp-type computation”. Stanford, 1986. Unfortunately this is not available online, as far as I know.