[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 |
Christian,
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.
The
(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?
Will