[Top][All Lists]

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

Re: [Chicken-users] Conflict between simple-macros and other extensions?

From: Alex Shinn
Subject: Re: [Chicken-users] Conflict between simple-macros and other extensions?
Date: Tue, 04 Oct 2005 20:40:46 -0500
User-agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Tue, 04 Oct 2005 15:43:00 -0000, Thomas Chust wrote:
> I hope I have put it as simply as possible while still being correct...  
> These are only the procedures that concern themselves with *loading* of  
> code, though. In addition there are at least two module systems available  
> for CHICKEN: The one that comes with the syntax-case egg and the one that  
> you were using, which comes with the simple-macros egg. These systems have  
> their own semantics to *import* code and to *separate namespaces*.

This is the important distinction.  Chicken lets you choose what
symbols are exported from an egg, but they are all exported to the
same top-level namespace.  This works so long as all exported symbols
have different names, but at some point conflicts are unavoidable.
This is when you turn to module systems which give you separate

In both of the above module systems, a module just looks like

  (module name (exports ...)
    code ...

The module form can contain any number of definitions, any of which
may be exported, but these are encapsulated and don't show up in the
top-level namespace.  To access the exports you use IMPORT inside the
MODULE form.  For example:

  (module named-arithmetic (plus minus)
    (define plus +)
    (define minus -))

  (plus 2 2)
  => Error: unbound variable: plus

  (module my-module ()
    (import named-arithmetic)
    (plus 2 2))
  => 4

Since you can also define multiple modules within an egg, or in a
script or at the REPL, IMPORT has no knowledge of where the modules
are defined.  If the named-arithmetic module were in an egg, you would
first need to load that egg (e.g. via require-extension), and then
IMPORT it to see the bindings.

I think currently the utf8 egg is the only egg that defines a module
which you need to IMPORT.  This is because the UTF-8 semantics may be
undesirable to load into the top-level, where other eggs may be
assuming STRING-REF always returns a value in the range 0-255.

All this can be a little confusing for the simple case where you just
want to use someone's egg without fussing with module systems.  This
was part of the motivation for the Common-Scheme module system.  It
provides yet another loading form IMPORT-EXTENSION, which behaves like
REQUIRE-EXTENSION, but also does an IMPORT if the extension happens to
be a module.


reply via email to

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