chicken-hackers
[Top][All Lists]
Advanced

[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




reply via email to

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