[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-hackers] compound modules
From: |
felix winkelmann |
Subject: |
Re: [Chicken-hackers] compound modules |
Date: |
Tue, 1 Sep 2009 21:06:16 +0200 |
On Tue, Sep 1, 2009 at 5:39 PM, Kon Lovett<address@hidden> wrote:
>
> Personally I would like to go further in splitting files (Unit library
> itself is kinda unwieldy), creating units like 'pathname' and 'system'.
> (Already mentioned by John Cowan as I was babbling.)
>
See my reply about this. I just wonder: what's the actual gain, as
compared to the extra typing, and figuring out what goes where?
Do we have a library size problem that must be taken care of? It doesn't
look like it does.
>
> The creation of a "compound module" for a convenient Chicken Utility Library
> to head-off a dive into insanity seems necessary.
>
> I do want to endorse the suggestion by Alex for an '(extend MODULE ...)'
> form; I build these manually. Would a consumer need to 'require-library' to
> get the binary of the extended module or just require the extending module
> or both? Should extending a subset of a module and/or renaming/prefixing the
> identifiers be supported?
>
I would suggest this:
[syntax] (reexport IMPORT-SPEC ...)
Performs an (import IMPORT-SPEC ...) and automatically exports all
identifiers imported
in that statement. I would leave the loading to the compound module
definition, so nothing
special would be necessary:
(module spiffy-framework (run-everything)
(import scheme chicken)
(reexport spiffy spiffy-utils (prefix spiffy-hacks hacks:))
(require-library spiffy lots-of-spiffy-stuff)
(define (run-everything) ...) )
cheers,
felix
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [Chicken-hackers] compound modules,
felix winkelmann <=