[Top][All Lists]

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

Re: [Chicken-hackers] modules vs. units

From: John Cowan
Subject: Re: [Chicken-hackers] modules vs. units
Date: Wed, 16 Dec 2009 20:52:06 -0500
User-agent: Mutt/1.5.13 (2006-08-11)

Thomas Bushnell BSG scripsit:

> What do (module ...) and (import ...) do at compile time?

The effect of (module foo ...) is to rewrite all the top-level definitions
(exported or not) inside it from (define bar ...) to (define foo#bar ...).

The effect of (import ...) is to pull the exported namess from defined
modules into the current namespace.  At top level, the modules "scheme"
and "chicken" are already imported, but not so when you define your
own module.

Import also has the power to selectively use, selectively ignore,
or rename either systematically or unsystematically the identifiers
as they are imported.  Thus you can say (import (prefix foo foo-))
to import the names in the foo module in the form foo-xxx.

> What about at load time in compiled code?

Module and import are syntax, so they disappear at compile time.

> Right now I have programs made out of Chicken units; each source file is
> a separate unit.  Many of the units are in a standard .a library, which
> is convenient.  There is some clear cross-over between units and
> modules; for example, both units and modules established protected
> namespaces, and both export bindings from those namespaces to be more
> globally visible.

Units don't permit selective importing and affect only the global
environment; on the other hand, Chicken can load a unit whose name is
computed at run time.

With techies, I've generally found              John Cowan
If your arguments lose the first round
    Make it rhyme, make it scan                 address@hidden
    Then you generally can
Make the same stupid point seem profound!           --Jonathan Robie

reply via email to

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