chicken-users
[Top][All Lists]
Advanced

[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: Stephen Eilert
Subject: Re: [Chicken-users] There are (module)s and there are (declare (unit s))...
Date: Thu, 10 Dec 2009 22:35:58 -0300

Now all that's missing are recipes on how to use these more effectively :)

Do not forget that you can (include) other files as well.

So far, I am using a combination of modules and includes.


--Stephen

programmer, n:
       A red eyed, mumbling mammal capable of conversing with inanimate monsters.


On Thu, Dec 10, 2009 at 3:04 PM, Will M. Farr <address@hidden> wrote:
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

_______________________________________________
Chicken-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/chicken-users


reply via email to

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