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

[Thomas Bushnell BSG]

This addresses well the "uses" aspect of units, but not the "exports"
part.

On Thu, 2009-12-10 at 12:04 -0600, Will M. Farr 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