[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] There are (module)s and there are (declare (unit s))

From: Will M. Farr
Subject: Re: [Chicken-users] There are (module)s and there are (declare (unit s))...
Date: Thu, 10 Dec 2009 12:04:40 -0600


On Dec 10, 2009, at 11:33 AM, Christian Kellermann wrote:

> one thing that keeps bugging me repeatedly is the concept of a unit
> as opposed to a module in chicken scheme. Could someone of the fine
> people on this list point me to some hints in the docs or explain
> here why there are those two separate things and what the differences
> are?

I was once puzzled by this, too, but I think I have figured it out now.  The 
other experts on this list can correct me if I make a mistake.

The short summary: modules work on syntax, controlling the mapping between 
symbols and bindings at top-level.  Units work at runtime, ensuring that code 
is initialized and top-level statements are executed in the correct order.  
Here's the long explanation:

* modules: a syntactic construct that associates names (symbols) with bindings. 
 In Chicken, all bindings are top-level; a module lets you access those 
top-level bindings with different names (or even hide---effectively---some 
bindings because there is no name existing inside the module that refers to 
them).  Purely syntax.  Modules are very important for macros, because free 
symbols in the output of a hygenic macro should refer to bindings according to 
the mapping in place *when the macro was defined*, not the binding in place 
when the macro is used.  

* units: a way to designate some code as intended to be included in a larger 
library or program.  The issue that units try to solve is that, in general, 
top-level forms in Scheme have side-effects.  Consider:

(define (foo x) (+ x 1))

When this is "executed", the global namespace is extended with a binding for 
'foo that refers to a function of a single argument that adds one to the 
argument.  This behind-the-scenes stuff must happen before any code runs that 
uses foo, or things break.  Units help ensure this.  The 

(declare (unit foo))

declaration states that the code in this file is designated by the name foo.  

(declare (uses foo))

declaration says "the following code uses definitions from foo", and ensures 
that all the behind-the-scenes stuff that needs to happen in the foo unit 
happens before executing any statements in the current file.  

In other words, units are a way of managing separate compilation of code.  Put 
some code into a unit and compile it.  Then "using" it in another bit of code 
will make sure that the code in the unit runs before any code in the "using" 
file (including all the behind-the-scenes stuff that needs to happen to 
initialize the bindings in the unit, etc).

Does this help explain the difference?  


reply via email to

[Prev in Thread] Current Thread [Next in Thread]